Date: Sun, 1 Feb 2004 17:52:48 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Don Lewis <truckman@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: Syncer "giving up" on buffers Message-ID: <20040201172521.X7622@gamplex.bde.org> In-Reply-To: <200402010119.i111J67E096098@gw.catspoiler.org> References: <200402010119.i111J67E096098@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040201172521.X7622>