linux-ext4 - Re: Porting Zfs features to ext2/3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 29 Jul 2008 21:00:26 +0000 (UTC)
From:	Szabolcs Szakacsits <szaka@...s-3g.org>
To:	linux-ext4@...r.kernel.org
Subject:  Re: Porting Zfs features to ext2/3

Theodore Tso <tytso <at> mit.edu> writes:
> 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.  

Those are old numbers of the unoptimized ntfs-3g driver, which could be 
at least 3-30 times better.

- create: until recently, when ext3 defaulted htree, the unoptimized 
ntfs-3g was 2-4x faster. But nobody seems to really care because it's 
not a real-world benchmark (creation of 0 byte size files).

- lookup: by enabling FUSE entry cache the performance will be exactly 
the same (no user space involvement), or the bottleneck will be the 
disk seek time and how an fs optimizes for it. 

> FUSE can do things to accellerate bulk read/write, 

FUSE can also cache attributes, positive/negative lookups, file data
and hopefully the new performance improving features, infrastructure 
being worked on will be added in the future too. 

> but metadata-intensive operations will (I suspect) always be slow.  

Basically FUSE file systems can be considered as in-kernel network 
file systems where the network latency is a context switch. Yes,
things need to be done a bit differently sometimes but achieving
high-performance even for metadata operations is not impossible.

> 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?

This is an implementation detail, irrelevant to FUSE. 

Regards,  Szaka

--
NTFS-3G: http://ntfs-3g.org



--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html