Announcement

Collapse
No announcement yet.

TFS File-System Still Aiming To Compete With ZFS, Written In Rust

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

  • TFS File-System Still Aiming To Compete With ZFS, Written In Rust

    Phoronix: TFS File-System Still Aiming To Compete With ZFS, Written In Rust

    The developers behind the Rust-based Redox operating system continue working on the "TFS" file-system that they hope will compete with the long-standing ZFS file-system, but TFS isn't being tied to just Redox OS...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I wish them luck, I am sure they will learn a lot about making file systems.

    Comment


    • #3
      I hope they don't make the same decision like the ZFS people that i cant add more drives to an array. (e.g. 3 disks in an raid5. if i want to add more disks i have to create another array or rebuild everything.

      Comment


      • #4
        Originally posted by Nille View Post
        I hope they don't make the same decision like the ZFS people that i cant add more drives to an array. (e.g. 3 disks in an raid5. if i want to add more disks i have to create another array or rebuild everything.
        Wait. That's what ZFS does? At least btrfs does that right then.

        Comment


        • #5
          Typo:

          Originally posted by phoronix View Post
          asynchronos operations,

          Comment


          • #6
            And Rust is the perfect language to write a filesystem in. If Brtrfs had been written in Rust, we wouldn't have all these problems with stability that Btrfs and other filesystems have issues with on a regular basis.

            Comment


            • #7
              Originally posted by rubdos View Post
              That's what ZFS does?
              Unfortunately.

              Originally posted by rubdos View Post
              At least btrfs does that right then.
              Yes, but btrfs and raid5/6 is another thing and in the past it was not know for its stability. And another thing that nobody can answer me. does check brtfs the files on each disk on read?

              Comment


              • #8
                Originally posted by Nille View Post
                And another thing that nobody can answer me. does check brtfs the files on each disk on read?
                Yes. btrfs and zfs are essentially the same in this regard. All blocks are checksummed and if there is a read error the data will be recovered from mirrored copies if available.

                As you've said, btrfs is anything but stable, especially on striped raid. I've had numerous issues over the last few years even with RAID1.

                It has some features that zfs lacks, and also lacks some zfs features.

                btrfs tends to have more features that are oriented around small systems, such as the ability to remove disks or modify raid in-place (just as mdadm allows, though a bit more flexibly as you don't need to migrate entire disks at once to do it due to the way chunks are implemented). It is also more flexible with subvolumes/datasets. snapshots are the same as clones in zfs and persist even if their original parent is removed (which is not possible in zfs without sending/receiving). In general a lot of things are more mutable in btrfs.

                zfs tends to have more features that are oriented around large systems, such as L2 ARC and ZIL. If you're dealing with 50 drives in your zpool chances are that you don't have a need to remove or add one disk at a time. zfs also tends to perform better and not eat your data.

                Another option is great. I have no idea how this will all play out, but while zfs is about as good as it gets right now for a stable filesystem, there is plenty of room for improvement.

                Comment


                • #9
                  Originally posted by Nille View Post
                  Yes, but btrfs and raid5/6 is another thing and in the past it was not know for its stability.
                  Still true today. RAID 5/6 isn't safe.

                  And another thing that nobody can answer me. does check brtfs the files on each disk on read?
                  It checks the files it is reading (i.e. parity isn't checked), if it detects issues it will go fetch parity and check it, if the check is passed it will use it to repair the corruption, if not passed it will complain on dmesg.

                  If you have no parity it will not check parity (duh) and will just complain on dmesg.

                  The main issue is that the file chosen for reading is not deterministic, so it's not "always drive A" or "always drive B" so you can get in situations where drive A is 100% fine and drive B develops silent corruption that will come to bite your ass if drive A gets corruption too.

                  Running a scrub will check everything, that's the whole point of it.


                  Here an example of what btrfs writes on dmesg when it finds checksum errors https://serverfault.com/questions/78...-recalculation
                  or this if it is metadata that is read on mounting https://bbs.archlinux.org/viewtopic.php?id=214958

                  Comment


                  • #10
                    Originally posted by rubdos View Post
                    Wait. That's what ZFS does? At least btrfs does that right then.
                    ZFS was developed under time pressure (relatively speaking) so they had to take some shortcuts like assuming plentiful ECC RAM and other stuff like that.

                    The reason was that they wanted to get it in production in a reasonable timescale, while btrfs whose goal is "doing it right" is taking a long while to get there.

                    Comment

                    Working...
                    X