From owner-freebsd-stable Thu Apr 11 14:29:56 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by hub.freebsd.org (Postfix) with ESMTP id 5692037B405; Thu, 11 Apr 2002 14:29:52 -0700 (PDT) Received: from i8k.babbleon.org ([66.57.86.84]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Thu, 11 Apr 2002 17:28:51 -0400 Received: by i8k.babbleon.org (Postfix, from userid 111) id F09C7BB39; Thu, 11 Apr 2002 17:28:41 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: Brian T.Schellenberger To: David Schultz , Ian Dowse Subject: Re: very old bug Date: Thu, 11 Apr 2002 17:28:41 -0400 X-Mailer: KMail [version 1.3] Cc: Coleman Kane , Bob Bishop , stable@FreeBSD.ORG References: <20020411100223.A64698@freebsd.org> <200204111604.aa64453@salmon.maths.tcd.ie> <20020411125651.A19217@HAL9000.wox.org> In-Reply-To: <20020411125651.A19217@HAL9000.wox.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020411212841.F09C7BB39@i8k.babbleon.org> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Simple solution: remove the floppy drive from your computer and replace it with a CD-ROM burner. Floppies don't hold enough data to be of much use these days anyway, or at least so I find. At any rate, this fix works for me. I mean, I guess it seems disturbing that this wasn't somehow fixed five years ago, but somewhat bizarre to tackle a floppy drive problem, of all things, in 2002. ("Yes, I have no floppy, I have no floppy today . . . . ") On Thursday 11 April 2002 03:56 pm, David Schultz wrote: | Thus spake Ian Dowse : | > If an error occurs when the write is finally attempted, the buffer | > cache is left in a predicament because it has no way to inform the | > filesystem of the problem, and it can't just throw away the data | > without risking serious filesystem corruption, and confusion within | > the filesystem code. The two remaining options are to keep retrying | > the write in the hope that it will eventually succeed, or panic. | > | > About the only other safe thing to do would be to completely | > disassociate the failing device from the filesystem and throw away | > any unwritten data. If the filesystem can handle the device going | > away like this without panicking, then maybe the user might be able | > to unmount it and contunue. | | Thanks for the explanation. It still bugs me that the failure occurs | when attempting to *read* a directory on which a write attempt failed. | Presumably the data of interest is still sitting in the buffer cache | and can be read without doing any I/O, so the filesystem code | shouldn't notice the problem. At worst, the buffer is locked, but | then the read request should block or fail. It doesn't seem to be | doing either; the filesystem code just loops as it attempts to read. | | Would a partial solution be to simply cause all I/O requests for a | particular filesystem to fail as soon as the first write failure is | detected? Then the user would be forced to unmount, at which point | the leftover dirty buffers could be discarded without risk of | corrupting the filesystem. If this approach is unreasonable, the | buffer cache should at least be able to support the illusion that | everything is working fine, at least as long as there are enough free | buffers. What does NFS do when the network link goes down? | | To Unsubscribe: send mail to majordomo@FreeBSD.org | with "unsubscribe freebsd-stable" in the body of the message -- Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) Brian, the man from Babble-On . . . . bts@babbleon.org (personal) ME --> http://www.babbleon.org http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message