Re: Syncer "giving up" on buffers

On Sat, 31 Jan 2004, Don Lewis wrote:

> On 31 Jan, Herculano de Lima Einloft Neto wrote:

[Someone wrote]
> >>>   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

> 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.

I saw this for a similar operation:

	tar ... to copy most of /usr/src to a new file system with soft-updates
	rm -rf /new/filesystem/*
	reboot using reboot(8) with no args (or maybe ctrl-alt-del)

BTW, copying /usr/src (or perhaps a slightly larger or smaller tree,
depending on the memory size or buffer cache size) shows other badness
in soft updates' buffering.  bufdaemon sometimes consumes almost 100%
of the CPU for a significant fraction of the copying time.  This makes
the copy go 2-3 times slower than it used to in favourable conditions
(source cached and target new).  My benchmarks show that this broke
sometime between 2002/06/05 and 2003/09/23.

Bruce