Dan Williams (dan.j.williams@xxxxxxxxx) said: > > - kernel tells userspace "hey, i unmounted this" > > (userspace freaks out because the filesystem the daemon is running on > > just went away) > mdmon does not know or care if the *filesystem* is read-only. It is > reading and writing /proc, /sys, and the raw disk devices. Your daemon has to be running from somewhere. That tends to be reduced to the initramfs that you've already deleted and switchrooted away from (in which case, good luck on upgrades of your userspace tools - you're stuck with the version in the initramfs you booted from, even if your later userspace tools end up using some later protocol). You can't run it from the rootfs, because that's a chicken/egg scenario (or you'll switch to it, and then be unable to mark it clean, because you can't mark the array r/o, because the filesystem is r/w, which you can't undo because the daemon is running on it...) Long-lived daemons running from the initramfs aren't really good. We don't run udev that way. > > - userspace frobs bit in superblock to say 'This array is CLEAN!' > ...not in this scenario no. Then when is the clean bit set? > > So, why isn't the ext* journal or filesystem unclean flag > > handled via a userspace file monitoring daemon, then? > > I'm not trying to be obtuse, but because it isn't. Put another way, > consider what extra tools the initramfs would need if we wanted to > support an ntfs-3g rootfs. You're asking for *the exact same thing*... just RAID specific. Bill -- 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
