Re: Lost buffers with mounted ext2fs

From: Don Lewis <truckman_at_FreeBSD.org>
Date: Sat, 19 Jun 2004 23:36:35 -0700 (PDT)
On 20 Jun, Tai-hwa Liang wrote:
> On Sat, 19 Jun 2004, Stefan Ehmann wrote:
>> On Fri, 2004-06-18 at 20:38, Michael Nottebrock wrote:
>> > IIRC this is a known bug (always 1 buffer left on reboot if any ext2
>> > filesystems are mounted (rw?, didn't check if ro also triggers it) at
>> > reboot/shutdown time, causing _all_ filesystems which were mounted rw to be
>> > left dirty).
>> >
>> > Does anybody have a fix yet? I'm currently using
>> > http://people.freebsd.org/~lofi/rc.shutdown.diff as a workaround...
>>
>> Yes, this is a bug that was introduced sometime last year:
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/56675
>>
>> This also happens if the ext2fs is mounted ro.
>>
>> AFAIK there is no fix available. I'd appreciate it very much though.
> 
> Sometimes I run into this behaviour even on a -CURRENT box without
> ext2fs.ko loaded. Though it's fairly hard to reproduce this lost buffer
> scenario, I'm wondering about whether this bug is not limited to ext2fs,
> but also UFS2 and smbfs?

I typically see this when I reboot immediately after running
mergemaster.  To avoid the problem, I use the old incantation of
sync'ing three times and waiting a bit before the reboot.

I'm pretty sure the problem is that the filesystem syncer is getting
shut down too early, while there are still items in the soft updates
work queue.  When the shutdown code tries to do the final sync, there
are a number of buffers that can't be written because of unsatisfied
dependencies, so the file system is left in an unclean state. I believe
that when portupgrade deletes the temproot tree, it generates a large
enough work list to trigger the problem.

I believe that the proper fix would be to speed up the syncer at
shutdown time and wait until it empties the work queue before
terminating.  Fixing this problem has been on my TODO list for ages.
Received on Sun Jun 20 2004 - 04:37:17 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:58 UTC