I think this misses the point of reboot notifiers (as I understand
There are *only* meant for "physical" sorts of things.
The comment in the code says:
* Notifier list for kernel code which wants to be called
* at shutdown. This is used to stop any idling DMA operations
* and the like.
md, lvm, knfsd and tux have no business registering a reboot notifier.
If they have something to shut down, it should be shut down in a
higher-level way, such as when a process gets a signal.
Currently md does register a reboot notifier, but this is wrong and
will go away just as soon as it can. Unfortuantely it cannot yet.
The problem is that if the root filesystem is on an md device, then
the device never received a final close, (bd_op->release) so it can
never make the array as "stable". That is what the current
reboot notifier does.
I am hoping that when Al Viro's changes to the boot/mount-root sequence
go in, the the root filesystem will really close it's device during
shutdown and the reboot notifier can go away.
Until then, I will change the priority for the md reboot notifier to
be very high, so that it is run first, as you suggest.
I also have this idea that if the raid1d or raid5d gets a signal, it
will switch into a mode where the array is marked stable after each
write, and then marked dirty before each write. This would have the
desired effect without requiring a final close....
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/