From: Luca Berra <bluca@comedia.it>
To: linux-raid@vger.kernel.org
Subject: Re: array always resyncs on boot
Date: Mon, 1 Dec 2008 08:47:23 +0100 [thread overview]
Message-ID: <20081201074723.GA18651@maude.comedia.it> (raw)
In-Reply-To: <493327F5.5010704@openhardware.net>
On Sun, Nov 30, 2008 at 06:55:33PM -0500, Tom Walsh wrote:
> Tom Walsh wrote:
>> Luca Berra wrote:
>>> On Sat, Nov 29, 2008 at 04:23:17PM -0500, Tom Walsh wrote:
>>>> <sigh> I need help!
>>>
>>> i'll try :(
>>>> I've overhauled the software, replaced the operating system
>>>> innumerable times with several Mandriva distros: 2008, 2008.1, 2009.
>>>> Removed the Mandriva kernel and compiled a stock 2.6.27.7 from
>>>> ftp.kernel.org. Ran the Seagate SeaTools on all four drives, no
>>>> errors. Ran the Western Digital Date Lifeguard on the two drives, no
>>>> errors. Changed from raid5 to raid10, still resyncs on boot.
>>>
>>> https://qa.mandriva.com/show_bug.cgi?id=40023
>>>
>>> read the whole of it.
>>>
>>
>> Ahhh, yes! Thank you!
>>
>>
>> I was reverting back to the 2008.0 distro and building a 2.6.27.7 kernel
>> when I saw your reply. Reading the bugzilla makes a whole lot of sense of
>> what I was seeing in the dmesg (re: md not finishing before the raid10
>> module started). Finishing out that build, I found that the 2.6.27.7
>> stock kernel would boot and NOT resync the array. That proves, to me,
>> something is wrong with the overall Mandriva 2009.0 system (as well as
>> 2008.1 which also fails miserably).
It is not limited to mandriva, redhat has the same 'feature' and afair
ubuntu was also the first to implement it.
> Just a follow-up. Add the internal bitmap to the arrays has cured the
> problem (mdadm --grow --bitmap=internal <mdX>). This is definitely a
> feature that I will consider adding to the existing raid5 arrays that I
> maintain out in the wild.
>
> Is this a non-destructive thing to do to a working array? Grow it with
> adding the bitmap? I did not make each member partition of the arrays
> consume the remainder of the drives, but left 50..150 blocks unused in them
> (found various 250Meg drives do not all have the same block counts between
> manufacturers).
It is a non destructive operation, it actually uses the space between
end of data and start of superblock. it does not care about 'free' space
on the drive.
L.
--
Luca Berra -- bluca@comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
next prev parent reply other threads:[~2008-12-01 7:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-29 21:23 array always resyncs on boot Tom Walsh
2008-11-29 21:37 ` Justin Piszcz
2008-11-30 1:07 ` Tom Walsh
2008-11-30 1:23 ` Justin Piszcz
2008-11-30 2:21 ` Tom Walsh
2008-12-01 17:46 ` Bill Davidsen
2008-12-01 18:03 ` Tom Walsh
[not found] ` <49357372.5030304@tmr.com>
2008-12-03 5:14 ` Tom Walsh
2008-11-30 8:07 ` Luca Berra
2008-11-30 9:50 ` Tom Walsh
2008-11-30 23:55 ` Tom Walsh
2008-12-01 7:47 ` Luca Berra [this message]
2008-12-11 2:46 ` Tom Walsh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081201074723.GA18651@maude.comedia.it \
--to=bluca@comedia.it \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).