Re: ZFS kernel panic
- From: Pawel Jakub Dawidek <pjd@xxxxxxxxxxx>
- Date: Wed, 29 Aug 2007 09:40:45 +0200
On Tue, Aug 28, 2007 at 04:57:51PM -0700, Paul Allen wrote:
From Pawel Jakub Dawidek <pjd@xxxxxxxxxxx>, Tue, Aug 28, 2007 at 10:55:55PM +0200:What !?! I suggest you man 2 fsync.
You can't ignore write error, because application already assumed the
write succeeded, which can lead to misbehaviour later. ZFS cannot yet
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@xxxxxxxxxxx http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
Attachment:
pgpYUHl80uUNk.pgp
Description: PGP signature
- References:
- Re: ZFS kernel panic
- From: Pawel Jakub Dawidek
- Re: ZFS kernel panic
- From: Bakul Shah
- Re: ZFS kernel panic
- From: Pawel Jakub Dawidek
- Re: ZFS kernel panic
- From: Paul Allen
- Re: ZFS kernel panic
- Prev by Date: Re: Encrypted zfs?
- Next by Date: Re: Encrypted zfs?
- Previous by thread: Re: ZFS kernel panic
- Next by thread: Re: ZFS kernel panic
- Index(es):
Relevant Pages
- Corrupt Superblock on /home
... I still haven't been able to boot up my FC4 box, beyond repair mode without a live distro
CD. ... Buffer I/O error on device hdb1, ... This last try at fsck -t ext3
/dev/hdb1 gave me "Attempt to read block from file system resulting in short read while trying
to open /dev/hdb1. ... (Fedora) - SUMMARY: how do I REALLY delete a file?
... leaving the rest of the file system intact. ... Wipedrive doesn't seem to be
available for Solaris, but might be of interest to ... run this on each filesystem
where the files from ... >Solaris' UFS] do not satisfy this assumption." ...
(SunManagers) - RE: Corrupt Superblock on /home
... without a live distro CD. ... Buffer I/O error on device hdb1, ...
When I went back to repair mode, the file system start up gives clean ... (Fedora) - Re: UFS Bug: FreeBSD 6.1/6.2/7.0: MOKB-08-11-2006, CVE-2006-5824, MOKB-03
... I don't know of a concerted effort by anyone to improve UFS in this ... automatically
mounting USB drives, these bugs would indeed be critical. ... The standard configuration of
Gnome runs ... done via amdand automatically as the file system gets accessed via
... (freebsd-stable) - Solaris 9 ufs logging
... Starting in Solaris 9 all ufs filesystems are logged by default. ... File
system is mounted read only. ... Please see the remount option described in mount_ufs.
... (comp.unix.solaris)