Date: Fri, 18 Oct 2002 11:35:54 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: hackers@FreeBSD.org Subject: Re: Patch to allow a driver to report unrecoverable write errors to the buf layer Message-ID: <200210181835.g9IIZsBX061970@apollo.backplane.com> References: <3DB048B5.21097613@FreeBSD.org> <200210181807.g9II7cBY024485@apollo.backplane.com> <3DB0516F.9BE00F57@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:> :
:> :There is a very easy way to trigger the problem: insert blank floppy
:> :...
:>
:> Your patch looks slightly incomplete to me, but the concept is reasonable.
:> The BIO_NORETRY test that sets B_INVAL should probably be done in
:> brelse(), not in bufwait(). It is the code in brelse() that actually
:> does the re-dirtying of the buffer in case of a write-error.
:
:Ah, actually I've initially put it into brelse() but then reconsidered
:a decision and moved it down into bufwait(). I'll move it back. ;)
Heh heh. Well, it seems to me that since it is the BUF abstraction
that has the error check / redirtying / retry code, then the BUF
abstraction should probably be responsible for the no-retry case as
well. The BIO abstraction is really designed to hold an I/O operation,
not really to hold meta operations. You could still specify a BIO
flag for it since it's a media hack of sorts, but the BUF code should
be responsible for processing it.
I dunno about a formal abstraction. We need to differentiate between
media which can and cannot remap blocks. A 'perfect' solution
would be far more complex. File data blocks would have to be
remapped at the filesystem level and meta-data would have to be
invalidated in-core (bitmap, inode blocks with write errors), and
the filesystem would have to be marked dirty on unmount. Then unmount
could safely destroy the buffers representing the write-error'd meta
data.
The VFS layer would definitely need to be involved. We have the
advantage in that the buffer cache is already logically mapped, but
it would still be a fairly sophisticated piece of work.
:> This re-dirtying is necessary in most cases to prevent filesystem
:> corruption. Otherwise the buffer may be thrown away and a re-read
:> may return the original pre-modified data, causing massive filesystem
:> corruption elsewhere (consider what that would mean for a bitmap block).
:>
:> I think it's perfectly reasonable to do away with the buffer in the
:> case of a floppy error, though.
:
:Thanks!
:
:-Maxim
Just a bit of history. Originally the buffer cache did not retry error'd
out writes. I changed it several years ago because the mechanism
was producing massive filesystem corruption in the face of disk write
errors. The floppy issue was a known issue at the time and I am quite
happy that someone is tackling the problem now!
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210181835.g9IIZsBX061970>