Re: ZFS with Linux: An Open Plea

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Tomasz Kłoczko wrote:
> On Mon, 16 Apr 2007, Stefan Richter wrote:
>> Tomasz Kłoczko wrote:
>>> Current FUSE implemntation can't be
>>> comparable in aspects of speed and probably never will be on using
>>> threads
>>
>> Did you measure this on a few hardwares and workloads?
> 
> Before asking firs you must try look on current ZFS on FUSE discuss
> phorums/docu .. like on:
> http://groups.google.com/group/zfs-fuse/feed/rss_v2_0_msgs.xml
> 
> ZFS on Solaris provides for many workloads better speed than any Linux
> technology on the same hardware but ZFS ond FUSE in current form
> provides lower speed than now avalaible Linux technologies.

There isn't a lot of useful facts in this last sentence.

> Example http://groups.google.com/group/zfs-fuse/msg/5b10c69707a46c07:

That's much more like it...

> "According to bonnie, I see 125 MB/s reads on ext3+RAID5, 65 MB/s on
> ZFS+RAID5 (using Linux's software RAID) and 20 MB/s on ZFS+raidz (using
> the same raw drives).  Writes are also proportionally slower.  The real
> performance hit with ZFS-FUSE was random accesses for lots of small
> files. The bonnie++ results showed something like 75 random seeks for
> ZFS vs 470 for ext3 (..)"

...although the tester doesn't say a lot about the test setup (e.g. no
word on the used hardware).

Another thread in the forum links to
http://www.ntfs-3g.org/performance.html which shows that filesystems
implemented on top of FUSE may actually yield performance in the same
league as classic Linux filesystems.  However that page doesn't say
anything about the test method either, beyond that bonnie++ was used.

> On the same phorun you can find threads with discuss about utilize
> treading under FUSE.

Could you point out what you meant by "not comparable... on using
threads"?  (Who is using which threads for what purposes; what are the
pertaining issues?)  Then I might be able to find those forum posts
which explain why a FUSE fs can never work comparably well "with threads".

>>> (very simmilar case to ALSA and mixing in user space ..
>>
>> Audio is about guaranteed latency, not "speed".
> 
> You meam "guaranteed worser latency" ?

I meant that the central requirement on the design and implementation of
audio subsystems is an (ideally guaranteed) bounded maximum of
latencies; and that's exactly the major point where I heard that there
are problems with ALSA driver components in userspace.  You were talking
about throughput of storage systems, for which latencies of the software
part of the stack do not play such a central role.  Therefore your
comparison appeared off the mark to me.
-- 
Stefan Richter
-=====-=-=== -=-- =----
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/