SoylentNews is people
SoylentNews
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/
(Score: 0, Informative) by Anonymous Coward on Monday August 28 2017, @12:49PM (4 children)
BTRFS is trash. I still don't trust it.
Relatively recently - mid-last year - fired up a new Arch build as a backup target, decided to give btrfs a try - most people were saying it was stable enough to try. Formatted, got a bit fancy with multi-disk and resilience, everything looks good, started backing up, dies part way through (Veeam backing up to Samba CIFS says its lost contact with the target). Machine unresponsive even from iLO. Reboot, everything just backed up is gone (empty volume) along with anything left over in tmp locations being corrupt and full of junk.
Reformat with a nice stable server-distro (CentOS7), btrfs still marked as experimental and this is a different kernel. Try a nice simple btrfs volume setup without fanciness, similar results.
XFS works brilliantly (and I've rarely had issues with ext4). The backup target is outfitted with proper ECC RAM, enterprise SAS HDDs, iLO diagnostics and so on - it's not a dodgy workstation or NAS. Veeam and pretty much anything else I throw at it can validate their chain signatures from beginning to end no worries across terabytes of data sitting for up to several years.
I could forgive an experimental filesystem being experimental. I could probably forgive some dodgy experimental features on a stable base that were clearly marked. I could get some useful diagnostics if the doco was helpful and faults provided useful debugging info. The documentation for btrfs doesn't clearly mark the parts that (if you search for long enough) you discover aren't recommended or stable, and basic operation of the FS is problematic.
I really wanted to like btrfs (it was perfect for my use case) but I can't trust it so I won't use it.
(Score: 4, Interesting) by KiloByte on Monday August 28 2017, @01:22PM (3 children)
And here's your problem. They use Red Hat's frankenkernels which are notoriously bogus: they mix a truly ancient base (3.10 for 7, 2.6.32 for 6) with backported features from the bleeding edge. Linux' I/O code moves pretty fast, patches tend to have nasty conflicts even three versions apart -- trying to backport complex code from 4.9 to 3.10 just can't possibly end well. And, despite trying something as risky, Red Hat doesn't even have a single btrfs-specific engineer. No wonders it keeps breaking.
Ceterum censeo systemd esse delendam.
(Score: 0) by Anonymous Coward on Monday August 28 2017, @02:52PM
I wasn't aware Poettering was in charge of the kernel too...
(Score: 3, Informative) by hoeferbe on Monday August 28 2017, @04:06PM (1 child)
You have an interesting characterization of Red Hat's compatibility policy [redhat.com]. I believe many of Red Hat's customers appreciate the stability that provides. As can be seen from Red Hat Enterprise Linux's life cycle [redhat.com], new features and significantly new hardware support is only provided in the first 5.5 years of its 10 year life cycle. (I.e. "Production Phase 1".) This means new features are not being added to RHEL6. They are being added to RHEL7's Linux kernel, but I would not go so far as to say 3.10 (which came out in 2013 and is a "longterm" release [kernel.org]) is "ancient".
And yet Red Hat appears to be successful at it! ;-)
I found this Hacker News thread on Red Hat's Btrfs notice [ycombinator.com] informative since it came from a former Red Hat employee.
(Score: 2) by sjames on Monday August 28 2017, @08:15PM
On the other hand, Debian stable isn't known for moving at breakneck speed either but it supports BTRFS just fine.
RH's continuing dedication to xfs is a bit puzzling as well. xfs made sense in the '90s on IRIX back when SGI was doing heavy video work on hardware where disk I/O was barely up to the task. In that environment, software willing to go out of it's way to work with the FS to maximize I/O could see substantial performance gains. None of that really matters much now, especially since the most interesting features had a hard requirement on specialized hardware that doesn't exist on most servers today. Further, even with the special hardware, the features were not ported to the Linux implementation anyway.
COW really looks like the future in file systems. It's early(-ish) days for BTRFS, but it really is a credible choice these days as long as you stay away from raid > 1 and according to some, zlib compression (lzo is fine). I could understand if RH wanted to make a play with ZFS instead of BTRFS, but abandoning all of it to keep pushing XFS makes no sense.