Stories
Slash Boxes
Comments

SoylentNews is people

SUSE Pledges Endless Love for btrfs; Says Red Hat's Dumping Irrelevant

posted by Fnord666 on Monday August 28 2017, @10:08AM   Printer-friendly
from the a-bitter-fs dept.

MrPlow writes:

Submitted via IRC for TheMightyBuzzard

SUSE has decided to let the world know it has no plans to step away from the btrfs filesystem, and plans to make it even better.

The company's public display of affection comes after Red Hat decided not to fully support the filesystem in its own Linux.

Losing a place in one of the big three Linux distros isn't a good look for any package even if, as was the case with this decision, Red Hat was never a big contributor or fan of btrfs.

[Matthias G. Eckermann] also hinted at some future directions for the filesystem. "We just start to see the opportunities from subvolume quotas when managing Quality of Service on the storage level" he writes, adding "Compression (already there) combined with Encryption (future) makes btrfs an interesting choice for embedded systems and IoT, as may the full use of send-receive for managing system patches and updates to (Linux based) 'firmware'." ®

Mmmmmm... butter-fs

Source: https://www.theregister.co.uk/2017/08/25/suse_btrfs_defence/

Original Submission

 
This discussion has been archived. No new comments can be posted.
SUSE Pledges Endless Love for btrfs; Says Red Hat's Dumping Irrelevant | Log In/Create an Account | Top | 30 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 2) by bzipitidoo on Monday August 28 2017, @02:45PM (3 children)

    by bzipitidoo (4388) Subscriber Badge on Monday August 28 2017, @02:45PM (#560256) Journal

    One of the last pieces was file system check for btrfs. I read that it finally exists, but "it is not well-tested in real-life situations yet." Yeesh.

    What's that? "Btrfs is fairly self-healing"?? No, built-in fsck on the fly the way btrfs does it isn't a replacement for offline fsck, you know, with the volumes NOT mounted. How else do you guarantee nothing else is altering the file system during a repair attempt?

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2  

  • (Score: 2) by KiloByte on Monday August 28 2017, @07:43PM

    by KiloByte (375) on Monday August 28 2017, @07:43PM (#560442)

    One of the last pieces was file system check for btrfs. I read that it finally exists, but "it is not well-tested in real-life situations yet." Yeesh.

    Eh? Offline fsck for btrfs exists since 2007, btrfs itself was merged into mainline kernel in 2009. WhereTF are you pulling this data from?

    No, built-in fsck on the fly the way btrfs does it isn't a replacement for offline fsck, you know, with the volumes NOT mounted. How else do you guarantee nothing else is altering the file system during a repair attempt?

    Unlike most filesystems, usually btrfs does not require to be unmounted in order to check for damage and repair it. Yeah, some damage can't be repaired live, but it's better if common cases don't require downtime.

    --
    Ceterum censeo systemd esse delendam.

  • (Score: 2) by darkfeline on Tuesday August 29 2017, @03:25AM

    by darkfeline (1030) on Tuesday August 29 2017, @03:25AM (#560655) Homepage

    Why do you even need fsck on a CoW file system? In personal experience, 99% of the use case for fsck is replaying the journal and finding orphaned inodes. CoW doesn't need the former, and the latter can be done online.

    --
    Join the SDF Public Access UNIX System today!

  • (Score: 4, Insightful) by TheRaven on Tuesday August 29 2017, @08:24AM

    by TheRaven (270) on Tuesday August 29 2017, @08:24AM (#560725) Journal
    There's a strange attachment to fsck, but it's a program that really shouldn't need to exist. There are three kinds of errors in a filesystem: those that can be detected automatically, those that can be detected and corrected automatically, and those that can't be detected automatically. The last set can, by definition, not be caught by fsck. The middle set shouldn't need fsck, because the filesystem code should be handling them automatically. The first set definitely shouldn't be relying on an offline tool, because you want to stop using a filesystem as soon as you've detected an unrecoverable error. Tools like fsck exist solely to work around either poor filesystem design or CPU limitations on ancient hardware. They have no place on a modern FS.
    --
    sudo mod me up