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? TimReceived 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