Syncer "giving up" on buffers
Bruce Evans
bde at zeta.org.au
Sat Jan 31 22:52:53 PST 2004
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
More information about the freebsd-current
mailing list