Date: Mon, 20 Sep 1999 13:23:58 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Bruce Evans <bde@zeta.org.au>, "Justin T. Gibbs" <gibbs@caspian.plutotech.com>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_bio.c Message-ID: <Pine.BSF.3.95.990920132254.6309D-100000@current1.whistle.com> In-Reply-To: <199909201936.MAA83732@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
There is always the possibility that we should propgate errors up to the
filesystem, and that filesystems should learn how to reallocate blocks..
(to new locations?)
On Mon, 20 Sep 1999, Matthew Dillon wrote:
> :> If a device "goes away", how should any pending buffers be marked? Does a
> :> umount -f cause pending buffers to be B_INVAl'ed? I'm pretty sure that
> :> we still can't rid the system of the knowledge of a mounted fs for a device
> :> that has disappeared, but I haven't checked recently.
> :
> :I think they should set B_ERROR in bp->b_flags and set bp->b_error
> :to something other than EIO (ENXIO perhaps), and brelse() should
> :only retry writes when bp->b_error == EIO. I/o beyond EOF is
> :already handled in this way in drivers ("something other than EIO"
> :is EINVAL). No device drivers set B_INVAL directly now; the above
> :fix is apparently for nfs.
>
> The fix to brelse() will result in no out-of-range buffers
> existing in the buffer cache at all by the time a umount is
> performed, so we are left with the question on how to deal with
> B_ERROR'd buffers that are otherwise valid (i.e. within the
> block range supported by the underlying device).
>
> At the moment those buffers stick around forever, because
> attempts to flush them (probably) generate another physical
> media I/O error.
>
> It could be argued that a umount -f should destroy such buffers
> after making one last attempt to write them to the media. In
> this it is simply a matter of taking a pass to flush them
> (in vinvalbuf?), and then determining that a forced-umount is
> in progress and that the buffers should be destroyed if the write
> failed (B_ERROR continues to remain set and the buffer continues
> to remain dirty).
>
> :umount -f doesn't cause buffers to be B_INVAL'ed. Writing of unwritable
> :buffers is retired endlessly. umount -f simply forces a write, and in
> :the best case, unmount(2) fails when the forced write fails. For some
> :filesystems, the write error is ignored and the unwritable buffer causes
> :a panic after unmount() blunders on. A fixed umount -f would invalidate
> :the buffers, perhaps after retrying a couple of times. However,
> :unmount() is really too late. Unwritable buffers can currently sit in
> :the buffer cache for as long as the system is up, causeing i/o on
> :every sync. They should be discarded after a few retries.
> :
> :I think umount -f once handled gone-away devices as well as possible
> :(by forgetting about their buffers). unmount() begins by flushing
> :all the buffers. Unwritable buffers used to be discarded immediately
> :by brelse().
> :
> :Bruce
>
> We cannot discard buffers with write errors until a forced unmount
> occurs, though perhaps we can add a ref count and stop trying to
> write them in the normal course of operations. The reason is that
> filesystem state is likely being stored in these buffers. Destroying
> them will 'undo' a change that the filesystem had made and assumes
> has been committed. For example, a change to a block bitmap.
>
> If we destroy the block and the filesystem attempts to read it in
> again, it will be re-read the (incorrect data) from the media
> (which may succeed even if the write failed), and now the filesystem
> will have a block bitmap that is completely bogus.
>
> The result is potential corruption of the filesystem past any
> hope of repair.
>
> This is why brelse() was changed in the first place and made not
> to discard buffers with write errors. Given the choice between
> a system complaining a lot and a system turning a filesystem into
> ash, I'd rather it complain.
>
> -Matt
> Matthew Dillon
> <dillon@backplane.com>
>
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990920132254.6309D-100000>