Announcement

Collapse
No announcement yet.

Linux Patches To Begin Removing ReiserFS From Default Kernel Builds

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

  • #11
    Originally posted by Healer_LFG View Post
    Oh boy, a ReiserFS article! I can't wait to read all the on-topic comments about the merits of the file system, and probably nothing else
    On Moronix you will be lucky to find an "on topic" article when it comes to ReiserFS.

    What you will find will be nothing but sick twisted jokes probably written by 12 year old script kiddies getting their jollies off.

    Comment


    • #12
      Is it common for FS to be removed? That seems like a strange idea as you may find some device using that FS later... I guess it'd be good if it was easy to move those deprecated FS to Fuse instead.

      Comment


      • #13
        Originally posted by geearf View Post
        Is it common for FS to be removed? That seems like a strange idea as you may find some device using that FS later... I guess it'd be good if it was easy to move those deprecated FS to Fuse instead.
        This filesystem was basically abandoned as soon as it was merged, which is why the next FS from Reiser got so much additional pushback from the kernel maintainers. Reportedly it still seems to work but has had worrying behavior for years, and I would not trust a modern kernel to mount one anyway.

        There's no one keeping it working in the kernel, and there would be no one to validate a port to FUSE.

        Comment


        • #14
          Originally posted by transwarp View Post

          This filesystem was basically abandoned as soon as it was merged, which is why the next FS from Reiser got so much additional pushback from the kernel maintainers. Reportedly it still seems to work but has had worrying behavior for years, and I would not trust a modern kernel to mount one anyway.
          Wasn't it maintained by RH or SuSe for all these years? Couldn't it continue working in the foreseeable future without maintenance at least in read-only mode?
          I forgot if R4 can mount R3 the same way ext can, maybe that'd be a workaround if Shishkin keeps working on his fork.

          Comment


          • #15
            Originally posted by geearf View Post

            Wasn't it maintained by RH or SuSe for all these years?
            Given that the push to start removing it came from a Suse employee, I don't think that it'll be getting much maintenance from that class of company.

            Comment


            • #16
              Originally posted by geearf View Post

              Wasn't it maintained by RH or SuSe for all these years? Couldn't it continue working in the foreseeable future without maintenance at least in read-only mode?
              I forgot if R4 can mount R3 the same way ext can, maybe that'd be a workaround if Shishkin keeps working on his fork.
              There's a continuum of "maintained." It compiles, it seems to work on tests. But no one is keeping up with kernel architecture changes, and e.g. the major change in locking a few years back broke some of its assumptions and it's reported to stall on actions like metadata reads.

              R4 is incompatible with R3, that was another huge problem that made the kernel team feel they'd had this codebase dumped on them while Reiser and his team moved on. They had a brief window to capitalize on when R3 shined over ext2, and they squandered it.

              Comment


              • #17
                Originally posted by transwarp View Post

                There's a continuum of "maintained." It compiles, it seems to work on tests. But no one is keeping up with kernel architecture changes, and e.g. the major change in locking a few years back broke some of its assumptions and it's reported to stall on actions like metadata reads.

                R4 is incompatible with R3, that was another huge problem that made the kernel team feel they'd had this codebase dumped on them while Reiser and his team moved on. They had a brief window to capitalize on when R3 shined over ext2, and they squandered it.
                Thank you for the details!

                Comment


                • #18
                  Originally posted by Healer_LFG View Post
                  Oh boy, a ReiserFS article! I can't wait to read all the on-topic comments about the merits of the file system, and probably nothing else
                  I will only post what Linus had to say on the matter, in a bang up of a thread. Here: https://lore.kernel.org/linux-fsdeve...ail.gmail.com/

                  So while reiserfs was mentioned as some kind of "good model for
                  deprecation", let's be *real* here. The reason nobody wants to have
                  anything to do with reiserfs is that Hans Reiser murdered his wife.

                  And I really *really* hope nobody takes that to heart as a good model
                  for filesystem deprecation.

                  Linus
                  Last edited by fitzie; 19 September 2023, 10:52 PM. Reason: more direct link

                  Comment


                  • #19
                    Originally posted by fitzie View Post
                    I will only post what Linus had to say on the matter, in a bang up of a thread. Here: https://lore.kernel.org/linux-fsdevel/CAHk-=wjHarh2VHgM57D1Z+yPFxGwGm7ubfLN7aQCRH5Ke3_=Tg@mai l.gmail.com/
                    Snarky, but the reply to that post does provide some valuable insight on the problem:
                    Well, I agree that's (consciously or unconsciously) the non-technical part
                    of the reason. But there's also a technical one. Since Hans' vision how
                    things should be didn't always match how the rest of the VFS was designed,
                    reiserfs has accumulated quite some special behavior which is very easy to
                    break. And because reiserfs testing is non-existent, entrusting your data
                    to reiserfs is more and more a Russian roulette kind of gamble. So the two
                    existing reiserfs users that contacted me after announcing reiserfs
                    deprecation both rather opted for migrating to some other filesystem.​
                    So, the reiserfs code has a lot of unique behaviour which make it difficult for others to maintain the rest of the kernel without breaking it, and because so few people care about it, breakage doesn't even get found, much less fixed.

                    As such, there's really little benefit in keeping it... it's one thing keeping working code that's not widely used but is easy to keep working. It's another to keep non-working code that's equally unused, and which creates difficulties for others to even keep it in a compiling state.

                    Comment


                    • #20
                      Originally posted by Delgarde View Post

                      Snarky, but the reply to that post does provide some valuable insight on the problem:


                      So, the reiserfs code has a lot of unique behaviour which make it difficult for others to maintain the rest of the kernel without breaking it, and because so few people care about it, breakage doesn't even get found, much less fixed.

                      As such, there's really little benefit in keeping it... it's one thing keeping working code that's not widely used but is easy to keep working. It's another to keep non-working code that's equally unused, and which creates difficulties for others to even keep it in a compiling state.
                      yeah, that conversation was really something else. I'm not sure I totally agree with Linus that keeping all these filesystems around "just because" is the right approach but the argument to toss them because they use buffer heads wasn't really a winning argument either. I don't think ancient unused filesystems really belong in the kernel, but there should be some sort of mtools like software (userspace, self contained filesystem interface that doesn't use FUSE/VFS) for the digital archeologists that no doubt will have some need to read those filesystems 100 years from now.

                      Comment

                      Working...
                      X