bug-hurd
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]