Syncer "giving up" on buffers

[Don Lewis]

On 31 Jan, Herculano de Lima Einloft Neto wrote:
> Bruce Evans wrote on Sep 1 2003:
>>> 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...
>  >
>> 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.
> 
>      A couple days ago I upgraded from 5.1RELEASE to 5.2CURRENT, only to
> find myself dealing with this situation. I didn't like the looks of it,
> so decided to go back to 5.2.1RC today.. and realize it is also there.
> Is this bug being tolerated so far?

I fixed one cause of this problem shortly before 5.2-RELEASE (running
fsck on the root file system in single-user mode and rebooting before
the file system is re-mounted read-write).  I believe there are at least
two other causes of this problem.

One cause that a lot of people run across is rebooting while an ext2
file system is mounted.  Bruce has done the analysis of this problem,
but nobody has stepped up with a patch to fix it.  The workaround is to
unmount any ext2 file systems before rebooting.

I've also seen this happen if I run the following sequence of commands:
	make installworld
	mergemaster
	shutdown -r now
and don't wait long enough between mergemaster and shutdown.  My
suspicion is that the syncer is being shut before all the soft update
dependencies have been resolved, and the unresolved dependencies are
preventing some buffers from being written.  I think mergmaster is
triggering the problem because it deletes a large directory tree just
before it exits.  Waiting a little while to shutdown works around the
problem by giving the syncer time to clean things up.