Re: Syncer "giving up" on buffers

From: Tim Robbins <tjr_at_FreeBSD.ORG>
Date: Tue, 2 Sep 2003 20:42:39 +1000
On Tue, Sep 02, 2003 at 05:10:48AM +1000, Bruce Evans wrote:

> Apparently the bug fixed in ext2fs/fs.h revs 1.3, 1.4 and 1.6 (etc.)
> was restored in rev.1.14.  I think this is because B_LOCKED buffers
> were ignored in the sync() in boot() and flushed later when
> vfs_unmountall() calls ext2fs_unmount(), but they are now seen in the
> sync() so vfs_unmountall() is not called.
> 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?

Received on Tue Sep 02 2003 - 01:42:43 UTC

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