Re: Porting Zfs features to ext2/3

[Eric Anopolsky <erpo41@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]

On Tue, 2008-07-29 at 12:46 -0400, Ric Wheeler wrote:
> > I haven't personally tried pulling the plug, but I've tried holding down
> > the power button on my laptop until it powers off. Everything works fine
> > and scrubs (the closest ZFS gets to fsck) don't report any checksum
> > errors. The filesystem driver updates the on-disk filesystem atomically
> > every five seconds (less time in special circumstances) so there's never
> > any point at which the filesystem would need recovery. The next time the
> > filesystem is mounted the system sees the state the filesystem was in up
> > to five seconds before the power went out. The FUSEness of the
> > filesystem driver doesn't seem to affect this.
> >
> Does that mean you always lose the last 5 seconds of data before the 
> power outage?

> The expected behaviour should be that any fsync()'ed 
> files should be there (regardless of the 5 seconds) and other 
> non-fsync'ed files might or might not be there, but that all file
> system integrity is complete.

fsync()s are one of the triggers that cause the filesystem driver to
update the disk more than once every five seconds. This can also happen
when the filesystem is very full and someone is writing to the disk. 

> We had an earlier thread where Chris had a good test for making a case 
> for the write barrier code being enabled by default. It would be neat to 
> try that on ZFS ;-) 

To my knowledge, write barriers are not available to FUSE filesystems.
Also, the maintainer of ZFS FUSE discovered that calling fsync() on an
open device file just plain does not work on Linux, so currently the
driver requests write cache flushes directly from the hardware.

> It would also be very interesting to try and do a drive hot pull.

I've got some vacation coming up...sounds like fun! Unless someone
specifically asks on here, I'll post the results in the ZFS on FUSE
mailing list.

Cheers,
Eric


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]