From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 16:19:01 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD8DD16A41C for ; Mon, 18 Jul 2005 16:19:01 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5933E43D45 for ; Mon, 18 Jul 2005 16:19:01 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-151-199-7-31.ROA.east.verizon.net [151.199.7.31]) by gromit.dlib.vt.edu (8.13.3/8.13.3) with ESMTP id j6IGIxav068543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2005 12:19:00 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost.Chelsea-Ct.Org [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.4/8.13.4) with ESMTP id j6IGIrJg052046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2005 12:18:53 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.4/8.13.4/Submit) id j6IGIrkM052045; Mon, 18 Jul 2005 12:18:53 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) From: Paul Mather To: Matthias Buelow In-Reply-To: <200507181514.j6IFEBoR001237@drjekyll.mkbuelow.net> References: <200507181514.j6IFEBoR001237@drjekyll.mkbuelow.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 18 Jul 2005 12:18:52 -0400 Message-Id: <1121703532.51580.35.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Cc: freebsd-stable@freebsd.org Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 16:19:01 -0000 On Mon, 2005-07-18 at 17:14 +0200, Matthias Buelow wrote: > Paul Mather writes: > > >Why would that necessarily be more successful? If the outstanding > >buffers count is not reducing between time intervals, it is most likely > >because there is some underlying hardware problem (e.g., a bad block). > >If the count still persists in staying put, it likely means whatever the > >hardware is doing to try and fix things (e.g., write reallocation) isn't > >working, and so the kernel may as well give up. > > So the kernel is relying on guesswork whether the buffers are flushed > or not... I don't know if you are just deliberately trying to be contentious, but that is a serious misrepresentation of what is happening. Quite obviously the kernel knows whether a buffer has successfully been flushed, otherwise a count of outstanding buffers would be meaningless. (Surely you're not saying the kernel simply guesses if a buffer has been flushed in maintaining its count of outstanding buffers? What would be the point of that?) If you calm down and think about it for a little, you'll realise what you suggest to do and what is actually done amount to the same thing in practical terms. It's all very easy to say to "write each buffer synchronously (and wait for the disk's response)," but what do you do when the buffer *does* get stuck and won't complete (e.g., because someone removed the floppy or USB disk, or your remote ggate server disappeared, or your hard disk is going bad, etc.)? Do you just bail immediately at that point? Or do you keep retrying in the hope it will complete? In the end, it comes down to waiting a certain amount of time for drivers to do their best and then giving up. The only real question is how long you wait, and maybe whether syncer is not waiting long enough (and hence how to extend the amount of time it is willing to wait until it gives up on buffers being unflushable). I'm not sure why that is fundamentally "madness." Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa