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

[rmoog]

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.

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.

[NobodyXu]

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.

[Quackdoc]

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

[rmoog]

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_Not_Meant_For_RAID5_or_6

https://www.phoronix.com/scan.php?page=news_item&px=Btrfs-Warning-RAID5-RAID6

https://www.reddit.com/r/btrfs/comments/960990/list_of_known_btrfs_raid_56_bugs/

https://www.reddit.com/r/btrfs/comme...ta_if_a_power/ (lmao sounds like FAT32 problem to me)

[uxmkt]

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:

# 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"

# 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"

[justusranvier]

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:

I thought that too for a while but recently I've become interested in bitrot protection and the only way to automatically recover from bitrot is if the filesystem can commit a layering violation and get access to the RAID details so it knows where to find the redundant copies.

Of course this has sent me down the path of investigating ZFS, not btrfs. I bought into the btrfs hype several times over the years and have been burned by it more than once.