ZFS kernel panic

Pawel Jakub Dawidek pjd at FreeBSD.org
Wed Aug 29 00:42:03 PDT 2007

On Tue, Aug 28, 2007 at 04:57:51PM -0700, Paul Allen wrote:
> >From Pawel Jakub Dawidek <pjd at freebsd.org>, Tue, Aug 28, 2007 at 10:55:55PM +0200:
> > You can't ignore write error, because application already assumed the
> > write succeeded, which can lead to misbehaviour later. ZFS cannot yet
> What !?! I suggest you man 2 fsync.
> fsync should return EIO if any write in the past has failed.

Maybe we have different manual pages, but mine doesn't mention anything
about writes in the past:)

Anyway, I did a test, because I wasn't sure how UFS is going to handle
this case:

1. Open a file, write 64kB of data and wait 35 seconds for SoftUpdates
   to flush cache to the disk.
2. Return an I/O error on this cache flush.
3. Write another 64kB.
4. Call fsync(2), flush next 64kB successfully.

If UFS remembers I/O errors, fsync(2) should return EIO.

And actually it does. I thought that when file system itself flushes the
cache and there's an I/O error then, it won't affect future fsync(2)s.
But yeah, UFS doesn't free failed buffers, but keeps them around.

Interesting thing is that even after fsync(2) returned an error, so
application was informed about the failure, UFS keeps trying to flush
this buffer. IMHO it should just give up.

Anyway, I still won't assume that fsync(2) will return EIO if a write in
the past failed... POSIX doesn't tell anything about it. It just says
"An I/O error occurred while reading from or writing to the file
system." - if there are no reading nor writting to the file system,
because buffers where flushed before (and failure occured then), I
understand that fsync(2) can return success.

> No program should make assumptions based on a successful return of write(2).
> Granted, many do; but applications where it really matters properly do fsync(2).

Agreed. In case of ZFS, there is probably no easy way currently to
remember failed writes, that's why it does what it does.

Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20070829/2a259213/attachment.pgp

More information about the freebsd-current mailing list