2011/9/23 <olafbuddenha...@gmx.net>: > Hi, > > On Wed, Aug 10, 2011 at 02:10:22AM +0200, Samuel Thibault wrote: > >> I've digged a bit in the libdiskfs syncing issue at shutdown. The >> scenario is the following: >> >> - halt or reboot is issued >> - S_startup_reboot() gets called in init which >> - calls reboot_system(), which >> - calls notify_shutdown(), which for each diskfs which registered itself >> - calls startup_dosync() with a 1m grace period >> - diskfs_S_startup_dosync() thus gets called in e.g. ext2fs, which >> - syncs everything and marks hypermetadata as dirty >> - inhibits RPCs >> - syncs everything again and marks hypermetadata as clean >> - resume RPCs >> - init takes back hand, and eventually tells mach to hang or reboot. >> >> But since RPCs are resumed, processes can continue writing to files, >> which makes ext2fs re-mark hypermetadata as dirty, and thus an >> "unclean!" message from ext2fs at reboot.
I wonder why a forced fsys_goaway isn't being used for this. It seems to fit better. > Nice catch! However, it explains only part of the problem: For me at > least, once the startup_dosync went through, the "unclean" problem shows > up only occasionally, and is generally harmless. The more serious issues > happen when halt/reboot is issued during or shortly after disk activity > (before the next regular sync), in which case the startup_dosync() > doesn't work properly, and instead is forcefully aborted after the grace > period (I presume)... If the reboot is interrupting a vm_copy operation, this could be the same bug as this https://lists.gnu.org/archive/html/bug-hurd/2011-09/msg00148.html
