SUSE Continues Working On Transactional Updates With Btrfs

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

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

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.

[jpg44]

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

Snapshots are a big and important feature that many people want. ZFS and UFS on FreeBSD had it for years. So its not very impressive and does not inspire confidence that the filesystem cannot get this right. As I said before, the concept of btrfs is right, volume management is best at the filesystem level. But you have to have a good implementation of it like ZFS has.

I dont understand the thinking of Fedora and the choice to go with xfs on LVM. There is no way thats better than a volume and snapshot integration into the filesystem. They say "btrfs has problems", but if so these are implementation bugs, its hard to argue that using LVM is actually a better way to do things than have a filesystem which is aware of multivolume support and snapshots. ZFS has been doing it for years, why cant we ever seem to get this done on Linux?

[RomuloP]

I can't see why people think snapshots are not working, I can say they are solid from 4.14+, I managed to do not sane things like maintaining 3000+ snapshots on RAID1 HDDs, mirrored to another HDD without a problem (until I noticed and cleaned it up), I have some very old partitions running fine, transitioned through 4 distro upgrades without pain... So I really don't get, honestly even if it failed I have locally 3 copies.

I really do want to move from fedora workstation to Silverblue so I don't manage updates atomicity with snapshots anymore, but will only do it the day BTRFS is supported because no other solution can allow me to have insanely quick, so in-depth, 100% bookable and accessible restoration points on other machines that can just be booted as the original one if something goes wrong.

[Charlie68]

For two years I have been using Btrfs with openSUSE both for / and for / home, never having data loss problems. The only time I lost my data was with Ubuntu using ext4, but this does not mean that ext4 is an inadequate file system.
Having a bad experience with a file system can happen regardless of which file system is in use.

[Zan Lynx]

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.

Beginners shouldn't be running defrag on everything. On hard drives the autodefrag option works pretty well and only defrags parts of a file as needed (like Firefox SQLite databases). On SSDs no one should care how many fragments the file is in because it doesn't matter.

[dfyt]

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.

I have had nothing be negative experiences with BTRFS and thats without a fancy setup. I recently backed up a 4TB drive to another identical drive, BTRFS used 200GB more with compression over XFS or even ZFS. No, it wastes space. Additionally whilst I haven't lost data I have often had times where the filesystem locks folders and you can't delete them etc. running it's repair tools does nothing and the only way to fix it was copy off, format and copy back. Sadly and I mean this honestly I wish it were even half as stable as FAT32 - features wise it's great but thats where it ends. I used to use openSuse and very quickly learnt to not have BTRFS as your root with that distro.

[Zan Lynx]

Additionally whilst I haven't lost data I have often had times where the filesystem locks folders and you can't delete them etc. running it's repair tools does nothing and the only way to fix it was copy off, format and copy back

That's likely to happen when the "folder" is not a directory, but is a subvolume. You cannot delete a subvolume using "rmdir" or "rm -rf". You have to use the "btrfs" command: "btrfs subvolume delete <subvolume>".

You can see the subvolumes with "btrfs subvolume list /" Or if you mounted a btrfs somewhere else like /data, "btrfs subvolume list /data"

[Charlie68]

The snapshots of Btrfs implemented as openSUSE did is a blessing, I do not know why people criticize Btrfs so much, to me on my systems has always worked very well, I would struggle without especially at work.
In the past I have received updates that have broken my system, it happened when I used Ubuntu and also with openSUSE, but having the ability to restore the system in a few minutes is priceless, especially when working with the PC.