From owner-freebsd-current@FreeBSD.ORG Wed Jun 30 09:55:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32B8716A4CE for ; Wed, 30 Jun 2004 09:55:45 +0000 (GMT) Received: from winston.piwebs.com (217-19-20-186.dsl.cambrium.nl [217.19.20.186]) by mx1.FreeBSD.org (Postfix) with SMTP id 6382D43D1D for ; Wed, 30 Jun 2004 09:55:44 +0000 (GMT) (envelope-from avleeuwen@piwebs.com) Received: (qmail 834 invoked from network); 30 Jun 2004 09:55:31 -0000 Received: from vincent.piwebs.com (HELO localhost) (192.168.0.84) by winston.piwebs.com with SMTP; 30 Jun 2004 09:55:31 -0000 Date: Wed, 30 Jun 2004 11:55:37 +0200 From: "Arjan van Leeuwen" To: "Don Lewis" References: <200406291030.i5TATxoM069816@gw.catspoiler.org> Message-ID: Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <200406291030.i5TATxoM069816@gw.catspoiler.org> User-Agent: Opera M2/7.52 (FreeBSD, build 724) cc: mckusick@mckusick.com cc: freebsd-current@freebsd.org Subject: Re: Giving up on x buffers - losing files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2004 09:55:45 -0000 On Tue, 29 Jun 2004 03:29:59 -0700 (PDT), Don Lewis wrote: > On 26 Jun, Don Lewis wrote: >> On 26 Jun, Arjan van Leeuwen wrote: > > I managed to get motivated and crank out the patch below. I'm still not > sure why the sync command seems to prevent the problem, but the sync > code in boot() seems to be unable to flush the buffers to disk. > > The way this patch works is that the syncer kernel thread is not > immediately terminated at kernel shutdown time. Instead, the syncer > thread is told to speed up and run through its work queue a few times > before terminating. > > One minor issue that I noticed but haven't yet figured out is that even > after the only items remaining on the syncer work list are the syncer > vnodes for each of the mount points, something is occasionally putting > the disk device vnode back on the work list. I suspect that when the > file system is getting synced, it is dirtying the superblock or summary > info. > > With this patch, the syncer takes noticeably longer to shut down, but > the final sync done by boot() finishes either immediately or within two > iterations, even after running mergemaster. > Yes, this works for me too. Is there any chance that this can be committed? It may slow down shutdown a bit, but if I have to choose between that and losing (important) files, you can give me a longer shutdown any time :). Arjan -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/