From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 15:14:11 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 C885216A41C for ; Mon, 18 Jul 2005 15:14:11 +0000 (GMT) (envelope-from mkb@mkbuelow.net) Received: from luzifer.incubus.de (incubus.de [80.237.207.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 639CB43D46 for ; Mon, 18 Jul 2005 15:14:11 +0000 (GMT) (envelope-from mkb@mkbuelow.net) Received: from drjekyll.mkbuelow.net (p54AA9CC3.dip0.t-ipconnect.de [84.170.156.195]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by luzifer.incubus.de (Postfix) with ESMTP id 6D32632973; Mon, 18 Jul 2005 17:17:03 +0200 (CEST) Received: from drjekyll.mkbuelow.net (mkb@localhost.mkbuelow.net [127.0.0.1]) by drjekyll.mkbuelow.net (8.13.3/8.13.3) with ESMTP id j6IFEBoR001237; Mon, 18 Jul 2005 17:14:12 +0200 (CEST) (envelope-from mkb@drjekyll.mkbuelow.net) Message-Id: <200507181514.j6IFEBoR001237@drjekyll.mkbuelow.net> From: Matthias Buelow To: Paul Mather In-Reply-To: Message from Paul Mather of "Mon, 18 Jul 2005 10:59:39 EDT." <1121698779.51580.15.camel@zappa.Chelsea-Ct.Org> X-Mailer: MH-E 7.84; nmh 1.0.4; XEmacs 21.4 (patch 17) Date: Mon, 18 Jul 2005 17:14:11 +0200 Sender: mkb@mkbuelow.net Cc: freebsd-stable@freebsd.org, Matthias Buelow 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 15:14:11 -0000 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... >You can enumerate the buffers and *try* to write them, but that doesn't >guarantee they will be written successfully any more than observing the >relative number left outstanding. That's rather nonsensical. If I write each buffer synchronously (and wait for the disk's response) this is for sure a lot more reliable than observing changes in the number of remaining buffers. I mean, where's the sense in the latter? It would be analogous to, in userspace, having to monitor write(2) continuously over a given time interval and check whether the number it returns eventually reaches zero. That's complete madness, imho. mkb.