SUSE Continues Working On Transactional Updates With Btrfs

[waxhead]

That's one thing that always scares me about Btrfs. I don't want to "set up" my filesystem. I just want it to do what it was designed to do without worrying if any of its features are going to wreck my data.

Then just mkfs.btrfs /dev/somedev and just go for it like you would with for example ext4.

[WolfpackN64]

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

That's one thing that always scares me about Btrfs. I don't want to "set up" my filesystem. I just want it to do what it was designed to do without worrying if any of its features are going to wreck my data.

[waxhead]

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.

The reason to stay away from snapshots (for beginners) is because defrag breaks reflinks and can increase space usage significantly. While there is nothing wrong with snapshots from a functional perspective it is easy to fool yourself if you don't know what you are doing and suddenly you are out of space.

I am also perfectly aware of the shortcomings (as well as benefits) from benchmarks, but if you for example run DUP on a single device for both data and metadata everything will be written twice. For some this is zero problem, for others it is not so yes, absolutely - for most desktop needs you hardly notice.

[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.

[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

[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.

[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.

[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

[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 [...]

[FireBurn]

Redhat for sure