SUSE Continues Working On Transactional Updates With Btrfs

[pal666]

At least redhat.

you are wrong twice. redhat didn't and redhat was already listed separately from several others

And it is totally understandable. Reliability > features.

what is totally understandable here is that you are having no clue. redhat doesn't support btrfs because redhat employs zero btrfs devs, so they just couldn't do it

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.

i guess backups are also labeled as too fancy

Apparently less than few years back mundane things like that could still break stuff.

mundane things like that are not supported by any competing filesystem at all

[untore]

Coreos (containerlinuxOS) used to ship with btrfs in the early builds but then switched to ext4+overlay not sure now, ironically coreos was acquired by red hat.
Is there a linux distro witch does the equivalent of opensuse with zfs? An Ubuntu flavor would even be OK.

[waxhead]

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.

I feel this has to be challenged.
1. How much data did you copy?
2. Was it large or small files?
3. How did you find out that BTRFS did use over 200GB more than ZFS/XFS?
4. Locked directories look like they could be subvolumes as Zan Lynx said. Are they?

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

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

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

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.

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

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

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