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

  • #51
    Originally posted by NobodyXu View Post

    Why not EXT4 or XFS?

    Both are the most stable filesystem on Linux you can get and neither of them is CPU and memory intensive.
    Ext4 is generic. It has no specific advantage or disadvantage.
    XFS is for large files, like databases.

    Originally posted by Quackdoc View Post

    hopefully this will line up with bcachefs nicely
    Now that's a name I haven't heard in 5 years. Are they still going or did they drop everything and go away? They used to be covered all the time on Phoronix back in 2017 and then they suddenly disappeared. I always thought perhaps they were funded and they didn't satisfy their investor's requirements so the funding was cut and they decided to merrily drop everything and go away forever.

    Comment


    • #52
      Originally posted by rmoog View Post
      Ext4 is generic. It has no specific advantage or disadvantage.
      Ext4 is still way better than ReiserFS, which is not actively maintained.

      IMHO actively maintained filesystems are always better more features, but less maintained ones, since without the maintenance, it is possible there are bugs in the filesystem that might eat my data.

      Comment


      • #53
        Originally posted by rmoog View Post
        Now that's a name I haven't heard in 5 years. Are they still going or did they drop everything and go away? They used to be covered all the time on Phoronix back in 2017 and then they suddenly disappeared. I always thought perhaps they were funded and they didn't satisfy their investor's requirements so the funding was cut and they decided to merrily drop everything and go away forever.
        Mr. Larabel actually did an article on it recently, I plan on using it soon, apparently linux-tkg builds it, and he AUR has a package for linux-zen with bcachefs. it isn't ready yet by any means for people who's data matters. but apparently it's pretty stable

        Comment


        • #54
          Originally posted by NobodyXu View Post

          Ext4 is still way better than ReiserFS, which is not actively maintained.

          IMHO actively maintained filesystems are always better more features, but less maintained ones, since without the maintenance, it is possible there are bugs in the filesystem that might eat my data.
          Btrfs isn't very stable despite being maintained and over advertised and yet somehow nobody dares to remove that dumpster fire from the kernel. It's by no means complete. It got accepted into the kernel despite not delivering a stable experience in all of its features, probably as a desperate attempt to hook people up who would normally use ZFS or a combo of normal filesystems with extra tools I'll mention later in this post. There are many testimonials about btrfs eating people's data without possibility to recover and there are even self-admitted warnings not to use their RAID5/6. If it doesn't work yet, why is it even there? That really calls into question who and why do they decide to accept such low quality code into the kernel.

          I'm really tired of filesystem devs trying to overdevelop their projects. You want RAID? There's MDADM. Does this, and only that, and it's stable. You want snapshots and pool provisions? We have a tool for that, it's called LVM. They played us for fools. You wanted encryption? We have LUKS for that too, there's no need to develop special snowflake unicorn encryption exclusively for ext4. Look what they demand our respect for in exchange for the kernel we made for them:
          https://linuxreviews.org/Btrfs_Was_N...For_RAID5_or_6
          https://www.phoronix.com/scan.php?pa...ng-RAID5-RAID6
          https://www.reddit.com/r/btrfs/comme..._raid_56_bugs/
          https://www.reddit.com/r/btrfs/comme...ta_if_a_power/ (lmao sounds like FAT32 problem to me)

          Comment


          • #55
            Originally posted by rmoog View Post
            I'm really tired of filesystem devs trying to overdevelop their projects. [...] You want snapshots and pool provisions? We have a tool for that, it's called LVM.
            (Going for devil's advocate here...) LVM is “just” a trivial container for data. But, we already have data containers, they are called filesystems. Since the filesystem kernel module will always be needed, we can ditch the LVM modules for at least one scenario, let's pick snapshots:
            Code:
            # pvcreate /dev/sda1
            # vgcreate vg0 /dev/sda1
            # lvcreate --size 64M -n data vg0
            # mkfs.xfs /dev/mapper/vg0/data
            # lvcreate -l100%FREE -s -n snap /dev/mapper/vg0/data
            # mkfs.xfs -ff /dev/mapper/vg0/data
            # blkid
            /dev/mapper/vg0-data: UUID="f5c80a46-6fa0-4e3b-8480-b2a473579d1a" BLOCK_SIZE="4096" TYPE="xfs"
            /dev/mapper/vg0-snap: UUID="993a9dda-ef44-42e1-ae08-8e2fa02413db" BLOCK_SIZE="4096" TYPE="xfs"
            Code:
            # mkfs.xfs /dev/sda1
            # mount /dev/sda1 /lvm
            # truncate -s 64M /lvm/data
            # mkfs.xfs /lvm/data
            # cp --reflink /lvm/data /lvm/snap
            # mkfs.xfs -ff /lvm/data
            # blkid /lvm/*
            /lvm/data: UUID="94a6d053-fc83-4ac5-86ec-21c9e165ae69" BLOCK_SIZE="512" TYPE="xfs"
            /lvm/snap: UUID="d964cdc5-331c-40ce-8966-a3ed2fd89f86" BLOCK_SIZE="512" TYPE="xfs"

            Comment

            Working...
            X