On Mon, 1 Sep 2003, Lefteris Chatzibarbas wrote: > I have a problem with kernels, built the last couple of days, where > during shutdown syncer is "giving up" on buffers. During the next boot > all filesystems are checked because of improper dismount. Here follow > the exact messages I get: > > Waiting (max 60 seconds) for system process `vnlru' to stop...stopped > Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped > Waiting (max 60 seconds) for system process `syncer' to stop...stopped > > syncing disks, buffers remaining... 8 8 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 > giving up on 6 buffers > Uptime: 41m20s > pfs_vncache_unload(): 1 entries remaining > Shutting down ACPI > Rebooting... > > After some testing I found out that this does _not_ happen if I manually > unmount my ext2 filesystems, before shutting down. In this case syncer > finishes without any problems. > > My last kernel which did not have this problem, is the one I built on > Wed Aug 27 23:14:12 EEST 2003.
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. Bruce _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"