Re: Syncer "giving up" on buffers

From: Robert Watson <rwatson_at_FreeBSD.ORG>
Date: Tue, 2 Sep 2003 10:07:13 -0400 (EDT)
On Tue, 2 Sep 2003, Tim Robbins wrote:

> > Rev.1.3 of ext2fs/fs.h (etc.) abuses B_LOCKED to do little more than
> > make the sync() ignore ext2fs's private buffers (its complications are
> > mainly to handle the resulting B_LOCKED buffers).  It wants to brelse()
> > the buffers so that their BUF_REFCOUNT() is 0 and the sync() in boot()
> > is happy to handle them.  In the original fix, I think the buffers
> > could be B_DELWRI and then the sync() would fulush them, but setting
> > B_DELWRI was wrong and was changed (in rev.1.4) to setting the private
> > flag B_DIRTY instead.  Rev.1.13 esssentially removes the brelse() and
> > adds a new complication (BUF_KERNPROC()) and keeps the old ones.  I
> > think the BUF_KERNPROC() is less than useful -- without the brelse()'s,
> > the buffers are completely private to the file system.
> 
> Is there any particular reason why ext2fs keeps these buffers locked
> instead of reading/writing them in when it needs to, or storing them in
> malloc'd memory and reading/writing them at mount/unmount time? Do we
> need to ensure that group descriptors & inode/block bitmaps are not
> written to disk until the filesystem gets unmounted, or is it merely to
> improve performance and simplify the code? 

FWIW, I've seen similar behavior to this on ext2fs-free systems: in
particular, the "fsck in single user mode prevents clean shutdown" with
UFS.  It doesn't seem to happen regularly, and I thought the problem had
"gone away", but now that I think back, it could just be that I hardly
ever fsck the root file system in single-user mode since most of my
kernels crash on diskless dev boxes.  And since we don't log the last few
lines of the reboot when file systems are unmounted and buffers are
flushing... 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Network Associates Laboratories
Received on Tue Sep 02 2003 - 05:08:05 UTC

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