Announcement

Collapse
No announcement yet.

Linux's ReiserFS Plan Is To Deprecate It, Remove The File-System In 2025

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

  • #31
    Originally posted by Paradigm Shifter View Post
    I don't think I've ever used ReiserFS. I vaguely remember it being an option at install time back with SuSE 9.3(?), reading the "still experimental" warning and going with... uh... XFS? I forget precisely.
    IIRC ReiserFS was the first journaling filesystem for Linux and SuSE used it briefly. XFS came shortly after but I think for a while it was not even mainlined. One of the problems with ReiserFS was that it was block-based not extent-based like XFS, so it was extremely inefficient for large files (but good for small ones). Another problem was that for some reason that I forgot it was not possible to use it on loopback mounted disk images, which was particularly annoying at a time when virtualisation was starting to become more mainstream (with VMWare).

    Comment


    • #32
      Originally posted by AndyChow View Post

      I bet there are plenty of mainframes out there running JFS.
      You're speaking about AIX? zSeries doesn't use JFS. And Linux-JFS was derived from OS2. It's completely different from the AIX-one.

      Comment


      • #33
        Originally posted by jacob View Post
        Another problem was that for some reason that I forgot it was not possible to use it [reiserfs] on loopback mounted disk images, which was particularly annoying at a time when virtualisation was starting to become more mainstream (with VMWare).
        Possibly that the repair tool, when run on /dev/sda, would find your loopback file and treat part of the content as belonging to the sda filesystem. It's a fear that could be raised with any filesystem repair tool that scans the disk in the absence or ignorance of the (possibly damaged) block/extent map, because the magic number for data structures(^1), if there even is one, seldomly includes the per-filesystem UUID.

        ^1 For example, `fs/xfs/libxfs/xfs_format.h:#define XFS_DINODE_MAGIC 0x494e`.
        Code:
        $ ls -ilgo xfs_format.h
        1431656793 -rw-r--r-- 1 61297 Jan 19 23:35 libxfs/xfs_format.h
        # hexdump -Cs $[1431656793*512] /dev/mapper/cr-auto-1 | head -n 10
        08a78400 49 4e 81 a4 03 02 00 00 00 00 02 21 00 00 02 21 |IN.........!...!|

        Comment


        • #34
          Originally posted by PuckPoltergeist View Post

          Linux-JFS was derived from OS2. It's completely different from the AIX-one.
          This fact was even used to dismiss part of SCO's lunatic allegations.

          Comment


          • #35
            Originally posted by set135

            A subtle note; yes ext4 can mount ext3 and ext2 if you have CONFIG_EXT4_USE_FOR_EXT2=y. There does not appear to be any ext3 only code left, but there is still separate ext2 code. I imagine it is still around so you can select only ext2 to minimize kernel size.
            I think it's because ext2 is still actively used in embedded systems, consumer devices etc. It has less metadata than ext4 and is more compact for very small files on very small storage, especially if it's mounted read only by default (so that the lack of journaling is not a problem). I remember that it was even used on floppies.

            Comment


            • #36
              Originally posted by zxy_thf View Post
              I just checked the commit message and interestingly enough the last commit for JFS is in Nov 2021, for a memory leak.

              So I'm guessing it's being passively maintained by a few people in interests?
              A lot of otherwise unmaintained code gets occasional fixes to make them compile due to other changes in the kernel, or due to issues found via scans by some tool.

              AFAIU after the initial inclusion into the kernel there was minimal work done on JFS, and besides some occasional one-offs I've never heard of it being used either.

              Comment


              • #37
                Originally posted by jacob View Post

                FAT is actively maintained and supported. ReiserFS isn't (I think it even still needs a giant kernel lock FFS).
                IIRC ReiserFS (and the TTY subsystem) was among the last holdouts when the kernel developers removed the BKL (big kernel lock). Someone eventually de-BKL'ified ReiserFS so that removal of the BKL could proceed. But I'm quite sure that was replacing the BKL with the minimum necessary changes, not introducing fine-grained locking for multi-core scalability that actively developed filesystems have seen.

                Comment


                • #38
                  is there a big burden for maintaining it? if not, I don't see the point of getting rid of it.

                  there's tons of use cases for keeping it in the kernel still. suppose I'm dumping some filesystem on an embedded platform and want to analyze its contents.

                  if you're still keeping floppy in the kernel, surely reiserfs can stay

                  Comment


                  • #39
                    Originally posted by jacob View Post

                    I think it's because ext2 is still actively used in embedded systems, consumer devices etc. It has less metadata than ext4 and is more compact for very small files on very small storage, especially if it's mounted read only by default (so that the lack of journaling is not a problem). I remember that it was even used on floppies.
                    The deployment of ext2 might be more than common impressions.
                    iirc when I was installing Debian 11 I founding surprisingly it is still using ext2 for /boot as the default option (I changed it to ext4 tho).

                    Comment


                    • #40
                      Originally posted by zxy_thf View Post
                      iirc when I was installing Debian 11 I founding surprisingly it is still using ext2 for /boot as the default option (I changed it to ext4 tho).
                      I wonder if it has something to do with facilitating multiboot. Most OSes have some form of ext2 support (Windows needs a 3rd party driver though).

                      Comment

                      Working...
                      X