[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libdiskfs sync issue at shutdown
From: |
Sergio López |
Subject: |
Re: libdiskfs sync issue at shutdown |
Date: |
Tue, 27 Sep 2011 16:05:43 +0200 |
2011/9/23 <olafBuddenhagen@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