If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

'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.

Comment

'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

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.

Comment

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?