Stories
Slash Boxes
Comments

SoylentNews is people

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

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.
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 KiloByte on Monday August 28 2017, @07:26PM (2 children)

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

    Most errors are not noticeable. You'll have a mangled texture in a game, a sub-second series of torn frames in a video, a slight corruption of data somewhere. A bad download you'll retry without investigating the issue, etc.

    On your disk, how much do all executables+libraries take together? It's 4GB or so. The vast majority of it is data.

    Being oblivious to badness makes people happy. I don't want a false sense of happiness.

    --
    Ceterum censeo systemd esse delendam.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 3, Insightful) by frojack on Monday August 28 2017, @10:47PM (1 child)

    by frojack (1554) on Monday August 28 2017, @10:47PM (#560564) Journal

    Easy for you to rev up the fud. Hard for you to produce any actual statistics.
    CERN tried, but 80% of the errors they found were attributable to a mismatch between WD drives and 3Ware controllers,
    and others pointed out the them that they could never separate those errors from any of their other detected errors.

    How many times has you BTRFS system detected and/or prevented errors?

    --
    No, you are mistaken. I've always had this sig.
    • (Score: 2) by KiloByte on Tuesday August 29 2017, @07:28PM

      by KiloByte (375) on Tuesday August 29 2017, @07:28PM (#561043)

      5 out of 8 disk failures I had in recent months involved a silent error. Four of those had nothing but silent errors, while fifth had a small number of loud errors plus a few thousand of silently corrupted blocks. Of the remaining failures, one was a FTL collapse (also silent, but quite hard to miss), while two were HDDs dying completely.

      Thus, every single of failures that didn't take the whole disk involved silent data corruption.

      Only one of those had ext4, and I wasted a good chunk of time investigating what's going on -- random segfaults didn't look like a disk failure in the slightest. The others had btrfs; they were either in RAID or I immediately knew what exactly was lost -- and more crucially, no bad data was ever used or hit the backups.

      Two days ago, I also had a software failure by stupidly (successfully) trying to reproduce a fandango-on-core mm kernel bug (just reverted by Linus) on my primary desktop with one of loads being disk balance. All it taken to find corrupted data was to run a scrub, all 30ish scribbled upon extents luckily were in old snapshots or a throw-away chroot so I did not even have to restore anything from backups. The repair did not even require a reboot (not counting one after the crash, obviously).

      By "disk" in the above I mean: 1 SD card (arm), 1 eMMC (arm), 1 SSD disk (x86), the rest spinning rust (x86).

      --
      Ceterum censeo systemd esse delendam.