SUSE Continues Working On Transactional Updates With Btrfs

[phoronix]

Phoronix: SUSE Continues Working On Transactional Updates With Btrfs

While Red Hat and several other Linux vendors have either deprecated Btrfs support or at least not embraced it like they originally talked up this "next-gen file-system" years ago, SUSE has continued supporting Btrfs both with openSUSE and SUSE Linux Enterprise...

http://www.phoronix.com/scan.php?page=news_item&px=SUSE-Btrfs-RPM-Trans-Updates

[Solid State Brain]

Which several other vendors have deprecated Btrfs?

[bitman]

At least redhat. And it is totally understandable. Reliability > features. Speaking as someone who fell a victim to broken filesystem after deleting some old snapshots. No it was not any raid setup or anything fancy. Apparently less than few years back mundane things like that could still break stuff.

[FireBurn]

Redhat for sure

[Solid State Brain]

I mean: which ones exactly other than Red Hat (that was already cited in the article)?

While Red Hat and several other Linux vendors have either deprecated Btrfs support or [...]

[nanonyme]

I'd say it's also not at all surprising Red Hat changed course. Fedora Silverblue is a PoC on that you can have atomic updates even on top of traditional filesystems with ostree. For storage they then build other solutions on top of XFS

[jacob]

Redhat for sure

Actually no. Redhat didn't "deprecate" Btrfs, they never used it at the first place. For a while they considered using it at some point in the future but then changed course, so it was more a case of switching from "RH may use Btrfs one day" to "RH is no longer considering maybe using Btrfs one day". For Btrfs and Btrfs users, this was a total non-event: a company that had not been using Btrfs would henceforth still not use it.

Apart from that I don't know of any other vendor who "deprecate" or otherwise turn their back on Btrfs. SUSE is using it natively by default and Ubuntu and Debian (and thus their derivatives) offer it as an option in their installers with excellent support and integration. That leaves Fedora as the only major distro other than RHEL (and its sibling CentOS) with no out-of-the-box, prime-time Btrfs support.

Disclaimer: I'm not a Btrfs developer or "stakeholder". I use it on my computers to my absolute satisfaction, but have otherwise no reason to barrack for or against it.

[jpg44]

I could swear I installed fedora on btrfs, so i think it does actually support it, but its not the default. Most distros support an array of filesystems and lets you choose but have their own default filesystem. There are two issues, the installer supporting it and kernel support. btrfs is a mainline kernel feature so basically any standard build of Linux will support it. btrfs isnt going anywhere. The concept of btrfs I think is a cleaner solution for the need of having a multi-volume filesystem and snapshots than using LVM.

I heard that people have had data loss with btrfs, I agree thats unacceptable and the bugs in the filesystem have to be fixed to provide a reliability assurance. This does not mean the concept of having volume management and snapshots at the filesystem level is bad, its actually a very good concept.

ZFS has a similar model to btrfs, so ZFS is an example of how it can work. ZFS is an excellent filesytem and more mature than btrfs so that can be another option, if one doesnt worrry too much about the BSD and GPL issue. Many had hoped that ZFS would be dual licensed under GPL, which would be nice, but has not happened.

[waxhead]

Again the myth about BTRFS instability issues... First of all , all valuable data needs backups. If you don't have backups the data is not by definition valuable enough for you and that goes for any filesystem. Second - please prove to me that BTRFS after kernel 4.4 eats your data or completely corrupts your filesystem or data unless you have some serious hardware failure (RAM) or insane setup with a gazillion layers.

This is what you do . Set up BTRFS with data + metadata profile as DUP on a single device or "RAID"1 like on a multi device filesystem. Stay away from the fancy stuff like quotas , snapshots, "RAID"5 / 6 and don't mess with deduplication or btrfs-convert. Then you're all good - at least on Debian

With such a simple setup you have precisely (if not more) features that any other off the shelf filesystem and it is significantly more reliable. Slower? oh yes, but more reliable. So if you value reliability and want to be sure your filesystem validate the data it reads before your computer uses it you are far better off with BTRFS than for example Ext3, Ext4, XFS etc... If you want speed go with XFS. If you don't care so much about a corrupted byte or a few lost files here and/or there go with EXT3/4.

I have had BTRFS save me from a controller failure, it has recovered corruptions on disk , it has even saved me from a dd fiasco where I accidentally overwriten the first 20 or so gigs of the wrong drive - all while the system was online, and I was able to recover gracefully online every time. One exception is the controller failure, the system was operational and it would have been possible to migrate the data from the failed (stuck) controller, but a reboot + a filesystem scrub fixed a few bytes here and there and all is good. I have run the same filesystem on Debian since 2013 now (but I admit that it was brave back then). Not a single hickup on the LTS kernels (or Debian testing) since kernel v4.4

[EarthMind]

Again the myth about BTRFS instability issues... First of all , all valuable data needs backups. If you don't have backups the data is not by definition valuable enough for you and that goes for any filesystem. Second - please prove to me that BTRFS after kernel 4.4 eats your data or completely corrupts your filesystem or data unless you have some serious hardware failure (RAM) or insane setup with a gazillion layers.

This is what you do . Set up BTRFS with data + metadata profile as DUP on a single device or "RAID"1 like on a multi device filesystem. Stay away from the fancy stuff like quotas , snapshots, "RAID"5 / 6 and don't mess with deduplication or btrfs-convert. Then you're all good - at least on Debian

With such a simple setup you have precisely (if not more) features that any other off the shelf filesystem and it is significantly more reliable. Slower? oh yes, but more reliable. So if you value reliability and want to be sure your filesystem validate the data it reads before your computer uses it you are far better off with BTRFS than for example Ext3, Ext4, XFS etc... If you want speed go with XFS. If you don't care so much about a corrupted byte or a few lost files here and/or there go with EXT3/4.

I have had BTRFS save me from a controller failure, it has recovered corruptions on disk , it has even saved me from a dd fiasco where I accidentally overwriten the first 20 or so gigs of the wrong drive - all while the system was online, and I was able to recover gracefully online every time. One exception is the controller failure, the system was operational and it would have been possible to migrate the data from the failed (stuck) controller, but a reboot + a filesystem scrub fixed a few bytes here and there and all is good. I have run the same filesystem on Debian since 2013 now (but I admit that it was brave back then). Not a single hickup on the LTS kernels (or Debian testing) since kernel v4.4

Why should anyone stay away from snapshots? They're a wonderful feature and work perfectly! If snapshots aren't available, there's mostly no reason to go for btrfs anyway.

As for the speed difference. In benchmarks you clearly see the statistical difference in read and write speeds, but in the real work, that's something else. I've been using btrfs for a long time now as my main drive (with the right mount options) and as my gaming drive and have never noticed clear differences in application performance or game loading speeds. So don't be fooled by all these fancy synthetic benchmarks. While they are an important factor to take into account for enterprise and server-side solutions, for desktop use they matter not much.