How come ZFS on Ubuntu is never thrown in the mix?

[devsk]

I see filesystem benchmarks for ext4/btrfs/zfs on BSD but never do I see zfs-fuse thrown in the mix.

I would love to see FS benchmarks to include zfs on ubuntu or gentoo using zfs-fuse.

[curaga]

Because it's much slower due to fuse. Considering it's near-same code, this would be a bench of fuse.

[devsk]

Because it's much slower due to fuse. Considering it's near-same code, this would be a bench of fuse.

Assumptions assumptions assumptions!

Have you tested it?

[curaga]

No, I have no interest in ZFS. Please prove me wrong, show a benchmark where a fuse fs is faster than a native same one.

Anecdotal personal evidence: everything I've ever used under fuse was slow.

[devsk]

No, I have no interest in ZFS. Please prove me wrong, show a benchmark where a fuse fs is faster than a native same one.

Anecdotal personal evidence: everything I've ever used under fuse was slow.

'a' is the speed of ZFS code, 'b' is the speed decrease by fuse and 'c' is the speed of btrfs. Its not necessary a-b < c... I have high hopes from ZFS code.

I am interested in knowing because I don't have resources that phoronix has to conduct such an experiment on a large scale (comparing various OS).

You may very well be right. But if we don't measure, we won't know.

This will also show folks at zfs-fuse what have they accomplished with 0.6.9 (which is a solid release). Whatever I have gathered from my limited testing, zfs-fuse is as fast native for seq reads, beating out native FS in small random reads/writes but falling way short (slightly more than half) on seq writes.

[kernelOfTruth]

'a' is the speed of ZFS code, 'b' is the speed decrease by fuse and 'c' is the speed of btrfs. Its not necessary a-b < c... I have high hopes from ZFS code.

I am interested in knowing because I don't have resources that phoronix has to conduct such an experiment on a large scale (comparing various OS).

You may very well be right. But if we don't measure, we won't know.

This will also show folks at zfs-fuse what have they accomplished with 0.6.9 (which is a solid release). Whatever I have gathered from my limited testing, zfs-fuse is as fast native for seq reads, beating out native FS in small random reads/writes but falling way short (slightly more than half) on seq writes.

this

you can also do just raw i/o comparison and will see that ZFS is at least as fast as btrfs - which means: the maximal read and write performance is achieved easily

the only requirement seems to be that you use a big arc-cache (ZFS' main cache) which should be obvious and only fair since the other filesystems included in the kernel also have much cache available

[RealNC]

No, I have no interest in ZFS. Please prove me wrong, show a benchmark where a fuse fs is faster than a native same one.

That's the wrong question. The correct question is "show me a bench where a fuse fs is not slower than a native same one."

Anecdotal personal evidence: everything I've ever used under fuse was slow.

Do you mean time or CPU? Because if you're basing this on CPU load, a native FS runs in the kernel and the CPU load won't be visible with top or whatever. This gives the false impression that a kernel FS doesn't consume CPU time.

[curaga]

Do you mean time or CPU? Because if you're basing this on CPU load, a native FS runs in the kernel and the CPU load won't be visible with top or whatever. This gives the false impression that a kernel FS doesn't consume CPU time.

Time, I haven't measured cpu usage.
On kernel cpu usage, doesn't that account for the sys column in top?

ref http://www.linuxhowtos.org/System/procstat.htm

system: processes executing in kernel mode