Eric Anopolsky wrote:
Please let me know if I'm getting off topic for the ext4-devel list. My
point is not to advocate ZFS over ext3/4 since ZFS still has its share
of issues. No resizing raidz vdevs, for example, and performance in
certain areas. My only point is to make it clear that ZFS on Linux is
available (and not necessarily a bad choice) to people reading the
ext4-devel mailing list looking for ZFS-like features like the original
poster.
On Mon, 2008-07-28 at 08:40 -0400, Theodore Tso wrote:
On Sun, Jul 27, 2008 at 10:15:59PM -0600, Eric Anopolsky wrote:
It's true that ZFS on FUSE performance isn't all it could be right now.
However, ZFS on FUSE is currently not taking advantage of mechanisms
FUSE provides to improve performance. For an example of what can be
achieved, check out http://www.ntfs-3g.org/performance.html .
Yes... and take a look at the metadata operations numbers. FUSE can
do things to accellerate bulk read/write, but metadata-intensive
operations will (I suspect) always be slow.
It doesn't seem too much worse than the other non-ext3 filesystems in
the comparison. I'm sure everyone would prefer a non-FUSE implementation
and the licensing issues aren't going to go away, but this post on Jeff
Bonwick's blog gives some hope:
http://blogs.sun.com/bonwick/entry/casablanca . Even so, not everyone
needs a whole lot of speed in the metadata operations area.
I also question whether
the FUSE implementation will have the safety that has always been the
Raison d'être of ZFS. Have you or the ZFS/FUSE developers done tests
where you are writing to the filesystem, and then someone pulls the
plug on the fileserver while ZFS is writing? Does the filesystem
recovery cleanly from such a scenario?
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.
Cheers,
Eric
Does that mean you always lose the last 5 seconds of data before the
power outage?
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 ;-) 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.
It would also be very interesting to try and do a drive hot pull.
Thanks!
Ric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
