On 02/06/2009 03:26 PM, Dan Williams wrote:
On Fri, Feb 6, 2009 at 1:08 PM, Bill Nottingham<notting@xxxxxxxxxx> wrote:
Dan Williams (dan.j.williams@xxxxxxxxx) 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@xxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
