Date: Thu, 11 Apr 2002 17:28:41 -0400 From: Brian T.Schellenberger <bts@babbleon.org> To: David Schultz <dschultz@uclink.Berkeley.EDU>, Ian Dowse <iedowse@maths.tcd.ie> Cc: Coleman Kane <cokane@FreeBSD.ORG>, Bob Bishop <rb@gid.co.uk>, stable@FreeBSD.ORG Subject: Re: very old bug Message-ID: <20020411212841.F09C7BB39@i8k.babbleon.org> In-Reply-To: <20020411125651.A19217@HAL9000.wox.org> References: <20020411100223.A64698@freebsd.org> <200204111604.aa64453@salmon.maths.tcd.ie> <20020411125651.A19217@HAL9000.wox.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <iedowse@maths.tcd.ie>:
| > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020411212841.F09C7BB39>