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

  • uxmkt
    replied
    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"

    Leave a comment:


  • rmoog
    replied
    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)

    Leave a comment:


  • Quackdoc
    replied
    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

    Leave a comment:


  • NobodyXu
    replied
    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.

    Leave a comment:


  • rmoog
    replied
    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.

    Leave a comment:


  • NobodyXu
    replied
    Originally posted by rmoog View Post

    I used to use btrfs for root filesystems in 2012-2017 and for log storage in 2015-2021. btrfs failed me as a root filesystem, it ate my Gentoo install. Then, I needed a filesystem that isn't very CPU and memory intensive, so I've decided to give ReiserFS a try. It works, it's does what it's meant for and not much else. I'm pretty happy with it.
    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.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by rmoog View Post

    I used to use btrfs for root filesystems in 2012-2017 and for log storage in 2015-2021. btrfs failed me as a root filesystem, it ate my Gentoo install. Then, I needed a filesystem that isn't very CPU and memory intensive, so I've decided to give ReiserFS a try. It works, it's does what it's meant for and not much else. I'm pretty happy with it.
    hopefully this will line up with bcachefs nicely

    Leave a comment:


  • rmoog
    replied
    Originally posted by Berniyh View Post
    In your case, is ReiserFS really the best option? Did you actually perform tests that led you to that conclusion or did you jump to it because of the usual statement that "ReiserFS is the best because many small files".
    What I want to say is: I'd check if it actually makes a difference and if not, I'd move on to another one.
    btrfs could be an alternative here as it has some improvements for small files like sparse files and tail packing.
    And in addition it supports checksumming (which I'd consider important for log files) as well as transparent compression and deduplication.
    However, it doesn't perform the best in every use case, so it really depends on what you're actually doing with those files and what operations are critical.

    Generally speaking, the approach of just spamming a file system with many small files seems very inefficient and broken.
    It might be better to do something about that than to adapt and use a rotting filesystem.
    Just saying.
    I used to use btrfs for root filesystems in 2012-2017 and for log storage in 2015-2021. btrfs failed me as a root filesystem, it ate my Gentoo install. Then, I needed a filesystem that isn't very CPU and memory intensive, so I've decided to give ReiserFS a try. It works, it's does what it's meant for and not much else. I'm pretty happy with it.

    Leave a comment:


  • Berniyh
    replied
    Originally posted by rmoog View Post
    Hey, I just wanted to chime in. I use ReiserFS on all of my computers because I need to keep around a large amount of log files. I think Linux will become less useful if ReiserFS goes away. My use case isn't served best by other filesystems available.
    In your case, is ReiserFS really the best option? Did you actually perform tests that led you to that conclusion or did you jump to it because of the usual statement that "ReiserFS is the best because many small files".
    What I want to say is: I'd check if it actually makes a difference and if not, I'd move on to another one.
    btrfs could be an alternative here as it has some improvements for small files like sparse files and tail packing.
    And in addition it supports checksumming (which I'd consider important for log files) as well as transparent compression and deduplication.
    However, it doesn't perform the best in every use case, so it really depends on what you're actually doing with those files and what operations are critical.

    Generally speaking, the approach of just spamming a file system with many small files seems very inefficient and broken.
    It might be better to do something about that than to adapt and use a rotting filesystem.
    Just saying.

    Leave a comment:


  • rmoog
    replied
    Hey, I just wanted to chime in. I use ReiserFS on all of my computers because I need to keep around a large amount of log files. I think Linux will become less useful if ReiserFS goes away. My use case isn't served best by other filesystems available. I would like to see one day that people let go of their grudge with the filesystem. It had nothing to do with Nina's death and this project is being needlessly targetted and harassed by the world at large because of Hans' involvement in the filesystem's development. We've gone completely mad and made the word "Reiser" the n-word of IT. Can we please stop this madness and sacrifice our hubris for a good filesystem designed for keeping large amounts of small files? Thank you.

    Leave a comment:

Working...
X