Quick question regarding RAID1
pza...@gmail.com
(mdadm) ...
The initial synching of the array naturally takes a good long time to
complete..
I was just curious to know: if i do a --remove on one of the array
drive devices and later do a --re-add for the same disk to bring it
back into the array will the resync process take as long as the initial
one? or will it go faster since it virtually has no differences between
itself and the peer drive it is now rejoining?
just passing the time with a question :)
thanks!
Pat
Jeroen Geilman
> I have a raid array currently building using linux software raid
> (mdadm) ...
>
> The initial synching of the array naturally takes a good long time to
> complete..
Why ? If you have just created this array both members will be empty.
It took roughly 5 minutes on my mirrored 36GB drives.
If you mean you started out with a single drive and later added a mirror to
that, yes, it might take a while, but then I would not do that to begin
with - I'd wipe out both drives, do a quick init and restore from backup.
> I was just curious to know: if i do a --remove on one of the array
> drive devices and later do a --re-add for the same disk to bring it
> back into the array will the resync process take as long as the initial
> one? or will it go faster since it virtually has no differences between
> itself and the peer drive it is now rejoining?
When you add a drive the system will probably assume it is a replacement -
the copy operation will take just as long in that case.
Unless the raid driver is really smart, and reads the data to compare it
before writing it over.
But that operation is only fast when both drives are guaranteed to be almost
identical in content - if you added a completely new drive this procedure
would take significantly longer than a dumb copy.
It's a lot more likely that mdadm will just do a dumb copy.
I think the documentation will tell you all you want to know about it.
--
All your bits are belong to us.
pza...@gmail.com
Jeroen Geilman wrote:
> pza...@gmail.com wrote:
>
> > I have a raid array currently building using linux software raid
> > (mdadm) ...
> >
> > The initial synching of the array naturally takes a good long time to
> > complete..
>
> Why ? If you have just created this array both members will be empty.
> It took roughly 5 minutes on my mirrored 36GB drives.
> If you mean you started out with a single drive and later added a mirror to
> that, yes, it might take a while, but then I would not do that to begin
> with - I'd wipe out both drives, do a quick init and restore from backup.
>
Yes I am starting from a pre-existing partition on my drive 0 when i
created the array. I did not want the files to be unavailable while
copying them from temporary storage or whatnot into the raid
> > I was just curious to know: if i do a --remove on one of the array
> > drive devices and later do a --re-add for the same disk to bring it
> > back into the array will the resync process take as long as the initial
> > one? or will it go faster since it virtually has no differences between
> > itself and the peer drive it is now rejoining?
>
> When you add a drive the system will probably assume it is a replacement -
> the copy operation will take just as long in that case.
> Unless the raid driver is really smart, and reads the data to compare it
> before writing it over.
> But that operation is only fast when both drives are guaranteed to be almost
> identical in content - if you added a completely new drive this procedure
> would take significantly longer than a dumb copy.
Maybe i wasn't clear but the drive i am removing is a previously
healthy mirror. Some minor changes may occur between removal and adding
but generally they will remain identical...
John-Paul Stewart
> Jeroen Geilman wrote:
>> But that operation is only fast when both drives are guaranteed to be almost
>> identical in content - if you added a completely new drive this procedure
>> would take significantly longer than a dumb copy.
>
> Maybe i wasn't clear but the drive i am removing is a previously
> healthy mirror. Some minor changes may occur between removal and adding
> but generally they will remain identical...
You were clear in what you asked.
What the previous poster was getting at (at least I think that's what he
was getting at---and what I was about to say until I saw his post) is
that for mdadm to distinguish between a "previously healthy mirror" and
a "brand new replacement drive" involves a lot of overhead. So mdadm
makes the assumption that it is a new drive and does a full re-sync.
IOW, mdadm doesn't know (doesn't care) that the drive has just been
removed and is almost up-to-date. All that matters is that the
"replacement" drive is not up-to-date so a full re-sync is done.
Jeroen Geilman
>>
>> > I have a raid array currently building using linux software raid
>> > (mdadm) ...
>> >
>> > The initial synching of the array naturally takes a good long time to
>> > complete..
>>
> Yes I am starting from a pre-existing partition on my drive 0 when i
> created the array. I did not want the files to be unavailable while
> copying them from temporary storage or whatnot into the raid
Then that explains it fully.
> Maybe i wasn't clear but the drive i am removing is a previously
> healthy mirror. Some minor changes may occur between removal and adding
> but generally they will remain identical...
Understood, but that won't matter to md.
It will see you adding a *new drive* to the array, and even if all the tags
and metadata are still present, the contents will not match the present
drive, and it will do a complete rebuild.
Anything else would be less safe, and could take longer.
But I may always be wrong - by all means read the documentation.
pza...@gmail.com
OK I see what you mean... Lets say though for arguments sake that I
really can't affort to rebuild the array whenever the drive gets
re-added... I have read through the man again and noticed the --bitmap
option for write-intent mode. It creates a mapping of recent changes in
the metadata of the array and mirrors it on all members.. this makes
the resync procedure much faster.. but is only available as of 2.6.13.
I am running on 2.4.33.. Any ideas about equivalent settings to create
such mapping that would exist in the 2.4 kernel?
pza...@gmail.com
OK I see what you mean... Lets say though for arguments sake that I
Jeroen Geilman
>
> OK I see what you mean... Lets say though for arguments sake that I
> really can't affort to rebuild the array whenever the drive gets
> re-added... I have read through the man again and noticed the --bitmap
> option for write-intent mode. It creates a mapping of recent changes in
> the metadata of the array and mirrors it on all members.. this makes
> the resync procedure much faster.. but is only available as of 2.6.13.
> I am running on 2.4.33.. Any ideas about equivalent settings to create
> such mapping that would exist in the 2.4 kernel?
Aargh ! awooowaaa...argh !
2.FOUR and it's still running ? ;-)
Depending on your distro, there may be a backport of the latest md code.
Then again, it may be dependent on 2.6 to do just that mapping thing.