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. -- 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
