Date: Thu, 11 Apr 2002 16:04:42 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: Coleman Kane <cokane@FreeBSD.org> Cc: David Schultz <dschultz@uclink.Berkeley.EDU>, Bob Bishop <rb@gid.co.uk>, stable@FreeBSD.org Subject: Re: very old bug Message-ID: <200204111604.aa64453@salmon.maths.tcd.ie> In-Reply-To: Your message of "Thu, 11 Apr 2002 10:02:23 EDT." <20020411100223.A64698@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[responding to a few similar questions] I'm not really familiour with all of the issues involved, but I think the basic problems is that the buffer cache provides a delayed- write interface that is used by the filesystems. A filesystem can ask for a buffer to be populated with data from a particular block on the device, it can modify the data, and then ask for it to be written back to the device "at some later stage". 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. Ian 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? <200204111604.aa64453>