From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 14:59:51 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 00F2116A41C for ; Mon, 18 Jul 2005 14:59:51 +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 869C243D45 for ; Mon, 18 Jul 2005 14:59:48 +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 j6IExkFB068347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2005 10:59:47 -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 j6IExe60051859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2005 10:59:40 -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 j6IExduH051858; Mon, 18 Jul 2005 10:59:39 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) From: Paul Mather To: Matthias Buelow In-Reply-To: <200507181435.j6IEZVWG000889@drjekyll.mkbuelow.net> References: <200507181435.j6IEZVWG000889@drjekyll.mkbuelow.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 18 Jul 2005 10:59:39 -0400 Message-Id: <1121698779.51580.15.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 14:59:51 -0000 On Mon, 2005-07-18 at 16:35 +0200, Matthias Buelow wrote: > Oliver Fromme writes: > > >buffers to disk. While it is doing that, it displays the > >number of remaining buffers, with increasing time intervals > >between them. If there are still buffers left after a > >certain number of intervals without change, the kernel > >gives up. > > Why is it doing this? Can't it just enumerate the buffers and write > them, one by one? 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. 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. 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