On Tuesday August 8, [email protected] wrote:
>
> Why we're updating it BACKWARD in the first place?
>
To avoid writing to spares when it isn't needed - some people want
their spare drives to go to sleep.
If we increment the event count without writing to the spares, the
spares quickly get left behind and won't be included next time the
array is assembled.
So on superblock updates that are purely for setting/clearing the
'dirty' bit, we rock back and forward between X and X+1, while leaving
the spares with 'X'. A difference of 1 isn't enough to leave a drive
out of an array, so the spares stay part of the array.
The 'X is clean, the X+1 is dirty, so if there is any inconsistency
at startup, the 'dirty' will win, which is proper.
Any other superblock change like drives failing or being added cause a
normal forward change of 'events' and spares get written to as well.
> Also, why, when we adding something to the array, the event counter is
> checked -- should it resync regardless?
If we know it to be in sync, why should we resync it?
This is part of a longer term strategy to plan nicely with hotplug.
What I would like is that whenever hotplug finds a device, the hotplug
system can call
mdadm --hot-plug-this-new-drive-somewhere-useful /dev/newdisk
(or something like that) and the drive will be added to an appropriate
array (if there is one).
So now you have the question: when do you actually activate an array?
Do I wait until there are just enough drives to start it degraded or
do I wait until all drives are present?
The later might never happen. The former might cause lots of
unnecessary resync.
With the above feature (hot add of a current drive doesn't cause a
resync) then I can activate the array as soon as there are enough
drive for it to work at all. It can then be read from even though it
isn't complete.
Once the first write happens we commit to the current layout and a new
drive will have to be resynced. but if the array becomes complete
before the first write, no resync will be needed.
Hope that makes it a bit clearer.
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
