Skip site navigation (1)Skip section navigation (2)
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>