Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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.

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

    Comment


    • #3
      Originally posted by curaga View Post
      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?

      Comment


      • #4
        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.

        Comment


        • #5
          Originally posted by curaga View Post
          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.

          Comment


          • #6
            Originally posted by devsk View Post
            '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

            Comment


            • #7
              Originally posted by curaga View Post
              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.

              Comment


              • #8
                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

                Comment

                Working...
                X