Re: [RFC PATCH 2/3] raid: external and internal metadata support

[Warren Togami <wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On 02/06/2009 03:26 PM, Dan Williams wrote:
> On Fri, Feb 6, 2009 at 1:08 PM, Bill Nottingham<notting-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>  wrote:
>> Dan Williams (dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org) said:
>>> Actually no, your not necessarily stuck with the mdmon from boot.  In
>>> a pinch you could "mdmon /proc/mdstat /".
>> Not really.
>>
>> You state:
>>
>>> One might say "just set the dirty bit, terminate, and wait for the
>>> mdmon in the rootfs to take over".  The problem is that a disk could
>>> fail in this window, and this event needs to be handled before the
>>> kernel does anything else to the array.
>> ...
>>> The clean bit can be set as soon as the parity data is in sync with
>>> the data on the other drives.  We typically wait for some period of
>>> write-inactivity to avoid needlessly touching the metadata after every
>>> write.
>> You shut down the machine. After a while, you get to the point where
>> you're getting ready to unmount the filesystem. Since mdmon's running
>> on it (if you started it post boot), you have to kill it. After that
>> point, there are going to be writes (a final sync, if nothing else,
>> when you unmount the filesystem.) And you won't be able to set any
>> RAID metadata flags then, as the daemon won't be running. So, doing
>> a later run of "mdmon /proc/mdstat" doesn't fully protect you.
>>
>
> mdmon needs some coordination with the shutdown scripts to be kept
> alive until the rootfs is marked readonly... actually up until the
> point where the rootdev can be marked readonly.
>
> If you take a look at Debian's killall implementation it has
> provisions to exclude fuse and other critical userspace process from
> killall.  A similar exclusion is needed for mdmon.

It appears we have no solution for this yet in Fedora 12.

https://bugzilla.redhat.com/show_bug.cgi?id=496843
This bug has a similar request for network block devices that need a 
userspace process.

Warren Togami
wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html