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

  • #11
    Originally posted by starshipeleven View Post
    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.
    Interisting Insight, I know that it has huge disadvantages not only the lisense thing, which is the major problem, of course bsd lovers will blaime linux the gpl or whoever for it, but most people dont switch to another os just because of a filesystem, especialy if you need a 5000 Dollar pc to use it. Most people need nas or very low power small cheap servers etc.

    And always this rush, so 2016 btrfs was not ready for bigger stuff. so if it takes btrfs till 1/2018 or something then its to late and garbage and somehow should never ever be considered at all, while ever a year ago it had alreade some advantages in some usecases. you can use it easily as root, you dont need 5mio gb ram so for most private non-professional users its most of the time already the better choice.

    Most normal people use raid 1 or something. But it helps to see some reason why zfs structuraly has a wrong design, that makes my guts feeling and experience with btrfs more backed up.

    So I am no religious btrfs supporter or something, I just find it absolutily inacceptable to use a filesystem that doesnt scale to lower end hardware, and where you have forever use some strange custom setups with kernel patching and shit ilke that.

    And its not only that, as far as I understand zfs lisense situation, they forked basicly a old version of it. So at some point they either have to reverse-engineer new stuff from oracle upstream or even become incompatible if they want to add new features. So in the long run there will be 2 incompatibel zfs versions.
    (but I might be wrong, I am happy to hear some alternative explenation).

    So if the lisensing of this new fs is good, and there are advantages over btrfs? I mean you hear great stuff about Rust things especialy that its faster, like C but better. I dont like the syntax of the language (lisp guy), but if other people do great stuff with it go for it.

    Are there any advantages over btrfs in the pipe or done already? Or is it just another me-too thing?

    Comment


    • #12
      Originally posted by mmstick View Post
      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.
      Hah ha. No.

      Most filesystem errors are logic errors, not coding errors. Rust is great, but if you tell it to multiply by 4 when you meant 3 it won't save you.

      Comment


      • #13
        starshipeleven thank you.

        ----------------------------

        About Cross Plattform. I hope to see it on Windows too.
        Last edited by Nille; 21 May 2017, 03:34 PM.

        Comment


        • #14
          Originally posted by starshipeleven View Post
          The main issue is that the file chosen for reading is not deterministic, so it's not "always drive A" or "always drive B"
          I would also add that the placement of the 2 copies of a RAID-1 block isn't deterministic.
          It's "which ever 2 drivers happened to have free space at that moment".

          Thus it's a bit more complicated for Btrfs to correctly load balance and see 2x read access gain.
          (as opposed as when the RAID-1 functionnality is used in MD raid or DM (e.g.: LVM). Copy N goes on disk N.
          If you receive 2 request at the same time, you know that you can sent on request to retrieve copy 1 and the other request retrieve copy 2. Each request will be then served from a different disk and thus you get read acceleration)

          Comment


          • #15
            Originally posted by Zan Lynx View Post

            Hah ha. No.

            Most filesystem errors are logic errors, not coding errors. Rust is great, but if you tell it to multiply by 4 when you meant 3 it won't save you.
            Many logic errors can be turned into compile time errors in Rust if you take advantage of the type system. TFS is doing just that, and going a step farther in creating a system to perform formal verification of TFS components. That said, you are actually incorrect here, as many of the bugs reported against filesystems actually would have been prevented by Rust, either by being outright illegal, such as use after free, or by design of the language influencing how the software is written and structured (ie: modular architecture instead of monolithic projects littered with NIH data structures; pattern matching and algebraic data types; better standard library and idiomatic practices). A quick look through the Btrfs logs, for example, and you still see use after free bugs even in 2017! Thanks a lot, C.

            https://patchwork.kernel.org/patch/9674105/
            https://patchwork.kernel.org/patch/9708721/

            Comment


            • #16
              Originally posted by mmstick View Post

              Many logic errors can be turned into compile time errors in Rust if you take advantage of the type system. TFS is doing just that, and going a step farther in creating a system to perform formal verification of TFS components. That said, you are actually incorrect here, as many of the bugs reported against filesystems actually would have been prevented by Rust, either by being outright illegal, such as use after free, or by design of the language influencing how the software is written and structured (ie: modular architecture instead of monolithic projects littered with NIH data structures; pattern matching and algebraic data types; better standard library and idiomatic practices). A quick look through the Btrfs logs, for example, and you still see use after free bugs even in 2017! Thanks a lot, C.

              https://patchwork.kernel.org/patch/9674105/
              https://patchwork.kernel.org/patch/9708721/
              Thanks for your profound insights!

              Comment


              • #17
                Originally posted by Zan Lynx View Post

                Hah ha. No.

                Most filesystem errors are logic errors, not coding errors. Rust is great, but if you tell it to multiply by 4 when you meant 3 it won't save you.
                What??? You mean the compiler doesn't magically guess what program you are trying to write so as to automatically rewrite your code to make it do what it should and fix your algorithmic errors? Really, what a piece of crap! ;-)

                Comment


                • #18
                  It would be interesting if it is ported to Linux. Linux would become the first mainstream OS with kernel parts written in something other than C.

                  Comment


                  • #19
                    Originally posted by jacob View Post
                    It would be interesting if it is ported to Linux. Linux would become the first mainstream OS with kernel parts written in something other than C.
                    Microsoft Windows (parts of it are C++) and literally every operating system written before UNIX (and even some continuing during the AT&T UNIX days) says "Hi". Also depending upon one's definition of "mainstream OS" L4 is C++ and there's a lot of DoD stuff built up around Ada.

                    Originally posted by jacob View Post

                    What??? You mean the compiler doesn't magically guess what program you are trying to write so as to automatically rewrite your code to make it do what it should and fix your algorithmic errors? Really, what a piece of crap! ;-)
                    While it's true that compilers can't alert to fundamental logic errors in algorithm design at it's most abstract level, the use of static analysis and heuristics can allow a compiler to flag code that may be bad or inefficient logic or an antipattern. If you want to see what this looks like, try writing C# code using monodevelop with it's source code analyzer turned on.
                    Last edited by Luke_Wolf; 21 May 2017, 10:52 PM.

                    Comment


                    • #20
                      Originally posted by Luke_Wolf View Post
                      Microsoft Windows (parts of it are C++) and literally every operating system written before UNIX (and even some continuing during the AT&T UNIX days) says "Hi". Also depending upon one's definition of "mainstream OS" L4 is C++ and there's a lot of DoD stuff built up around Ada.
                      Yes, Multics for example was in PL/1 etc. None of these are what I would call mainstream OSes, though. Windows uses C++ in large parts of its userland but the NT kernel is AFAIK pure C (plus assembly, obviously).


                      Originally posted by Luke_Wolf View Post
                      While it's true that compilers can't alert to fundamental logic errors in algorithm design at it's most abstract level, the use of static analysis and heuristics can allow a compiler to flag code that may be bad or inefficient logic or an antipattern. If you want to see what this looks like, try writing C# code using monodevelop with it's source code analyzer turned on.
                      I agree, it was just a joke. BTW I'm a huge fan of static analysis and strongly, statically typed languages.

                      Comment

                      Working...
                      X