[lproven]

Hi. Article author here.

I worked for SUSE from 2017 to 2021. Because of that, I ran openSUSE on my work computer. Btrfs self-destructed on me, on 3 different PCs, about twice a year in that 4-year period.

Not myth. Not from t'Internet. Direct personal experience.

Btrfs `df` lies. You, and programs, can't get an accurate estimate of free space. OS snapshots fill the volume, volume corrupts, new install time. Over and over again.

I do not trust Btrfs and since the Btrfs zealots are in denial and will not confront the very real problems, I don't think it will ever get fixed.

[LargoLasskhyfv]

Yah well. Do some housekeeping then? I mean if the Distro delivers automagically snapshotting in intervals, during installation of packages, or whatever they fancy?

It's not like you'd need those for all eternity. By housekeeping I meant deleting them from time to time, with easily clickable tools, which exist(now/meanwhile), and DO give an overview. Maybe have to 'rebalance' afterwards, which can go wrong if the 'housekeeping' was too late, or something. OTOH the 'rebalancing' can be automated, from the beginning.

I'm sure similar haphazards (regarding common tools like df/du not being able to give an exact overview of remaining capacity) exist under ZFS, at least when your'e using compression.

[lproven]

No. That is the simple answer. I refuse.

I will clean up my own mess. If I take snapshots, it's my job to clean them up.

If the OS does its own then the OS can do the work and clean up its own mess.

More to the point, if the OS's developers thought this was a good idea, then complete the work, finish the job, track the space usage and never ever do operations needing lots of space without checking that space is available or making it available.

This is bad design and bad implementation. It is not my job to fix their omissions.

[LargoLasskhyfv]

Yah. Maybe (or even probably, given the history and all the (not even that anecdotical) evidence of all the gotchas and oopsies that happended so far) I'll eat chalk.

But so far I'm really enjoying my new hot technotoy, in combination with some other 'crazy' tools, like zram, profilesync-deamon for the browser, a really 'riced' kernal...err kernel with all sorts of powerful patches, and even most parts of the userland compiled with optimizations to the limits of my cpu, even the browser!

ISTR you mentioned the crappy default partioning suggestions from another OS in another thread, which seem inflexible because of the potential waste of space for different directories like /usr/var/serv/somecrap/whatnotelse/GO/HOME!, which really can't be known in advance for casual desktop-use, and I concure.

But with BTRFS-subvolumes that shit doesn't matter anymore! Whee! :)

I'll wait and see, and will abuse the really unexpectedly well working combination of components and their versions and settings to the max, not having experienced hitches, glitches, or even crashes so far.

But anything which could get lost is backed up incrementally to elsewhere anyways, just in case.

[lproven]

OK, that's perfectly fair. Enjoy! Seriously!

My take is just that, in the 21st century, I do not expect a Linux distro in normal routine use to crash and corrupt its disk. Not _ever._ That was acceptable in the '90s when it was new, but not now.

For the SUSE folks to complain that "U R doin it wrong" doesn't wash.

E.g. for an OS that takes a single-digit number of gigabytes of disk space, a 32GB disk partition should be plenty and it should never fill that up.

I note that recent releases of openSUSE disable Snapper if given a root volume of <= 20GB. Maybe that was due to me and my bug reports. I don't know. It's a rotten answer, though: "OK, this dude's weird usage breaks our snapshot system, so what we'll do is turn it off."

The correct answer is to fix the snapshot system. A better one is to fix the filesystem.