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: 4, Interesting) by requerdanos on Monday August 28 2017, @05:55PM (2 children)

    by requerdanos (5997) Subscriber Badge on Monday August 28 2017, @05:55PM (#560358) Journal

    I use brtfs with compression on an SSD on my /home on this machine. Interesting observations:

    First, it's fast.

    Second, I can reliably generate a kernel panic by mounting a btrfs volume with -o compress-force=zlib and then copying a nontrivial amount of data to it. Boom, dead every time. Using lzo instead of zlib results in no problems. Now, is this because btrfs has serious problems, or is that a problem with early Ryzen chips (which this machine has)? I don't know but I have seen other reports of btrfs compression "crashing" so it might not be "just me."

    And finally, for years the brtfs wiki [kernel.org] has said the following:

    Can I determine what compression method was used on a file?
    Not directly, but this is possible from a userspace tool without any special kernel support (the code just has not been written).

    So, the code has just not been written? (Windows NT had this in the mid-90s via the compact [microsoft.com] command.) Without this code, there is essentially no way to see how much space any given files are taking up on disc. It would be very nice for this to not be missing.

    Starting Score:    1  point
    Moderation   +2  
       Interesting=2, Total=2
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  
    Total Score:   4  

  • (Score: 3, Informative) by KiloByte on Monday September 04 2017, @07:59PM (1 child)

    by KiloByte (375) on Monday September 04 2017, @07:59PM (#563552)

    'ere you go [github.com]. Alas, the ioctl requires root, and the code is a first working stab, but at least the "working" part seems to be not an exaggeration. And there's a big pull request waiting already, before I even had a chance to clean it up ☺

    --
    Ceterum censeo systemd esse delendam.

    • (Score: 2) by requerdanos on Monday September 04 2017, @08:12PM

      by requerdanos (5997) Subscriber Badge on Monday September 04 2017, @08:12PM (#563555) Journal


      195396 files.
      all 62% 37G/ 59G
      none 100% 23G/ 23G
      zlib 22% 2.6G/ 11G
      lzo 44% 11G/ 24G

      I give you my warm thanks. I really appreciate it.