Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Aug 2007 09:40:45 +0200
From:      Pawel Jakub Dawidek <pjd@FreeBSD.org>
To:        Paul Allen <nospam@nospam.com>
Cc:        current@freebsd.org, Pascal Hofstee <caelian@gmail.com>
Subject:   Re: ZFS kernel panic
Message-ID:  <20070829074045.GA42667@garage.freebsd.pl>
In-Reply-To: <20070828235751.GB13200@hurl.ugcs.caltech.edu>
References:  <20070828180228.GD39562@garage.freebsd.pl> <20070828204834.9A7F85B3B@mail.bitblocks.com> <20070828205554.GI39562@garage.freebsd.pl> <20070828235751.GB13200@hurl.ugcs.caltech.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

--UugvWAfsgieZRqgk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 28, 2007 at 04:57:51PM -0700, Paul Allen wrote:
> >From Pawel Jakub Dawidek <pjd@freebsd.org>, Tue, Aug 28, 2007 at 10:55:5=
5PM +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.
>=20
> 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 fs=
ync(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.

--=20
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!

--UugvWAfsgieZRqgk
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQFG1SL9ForvXbEpPzQRAvHMAKDaEiseQx954UFoQfkAbUHgqrf6RgCeOIFs
Es0JrVq1syPQQjM3uLRyeuk=
=b26E
-----END PGP SIGNATURE-----

--UugvWAfsgieZRqgk--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070829074045.GA42667>