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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
