Re: btrfs - ready for prime time. Not.
That is why I always bring up this subject, and that is why yet again I link to both to an external site, and to SUSE's own instructions.
Btrfs is a rich, clever filesystem, that can do impressive things.
But it has two weaknesses that IMHO are fatal flaws:
 It does not give a straight answer to the classic `df` command. It will not say how much space is free. If it runs out of free space due to snapshots, it will not automatically delete them and continue operating -- its designers see that as the OS' responsibility. SUSE does not handle this case and will continue allocating space.
 If the filesystem fills up, or power fails at a bad time, or there is a media fault, or some other error, Btrfs filesystems can corrupt in reasonably common failure scenarios. If they do, it is almost impossible to repair them.
To have no working free-space estimate is a serious flaw. To have no working repair command is a serious flaw. Given that flaw #1 can lead to corruption and flaw #2 can't fix it, for me, that is a deal breaker.
That is why I write about it.
Things SUSE could do:
* Make the package manager aware of space usage by snapshots.
* Make it able to estimate space usage by the snapshot resulting from installation of new package(s) and account for that before proceeding.
* If there is inadequate space, then automatically resolve this.
The easy way: do not proceed if the action is likely to fill the volume.
The smart way: if the space is used by snapshots and there are later known-working snapshots, then automatically prune older snapshots to ensure the disk does not fill up and the requested action can complete.
In other words, make RPM and/or Zypper aware of snasphot space usage and handle it intelligently.
Other possible actions:
* Don't rely on Btrfs and don't inherit Btrfs flaws. If Btrfs snapshots hinder free-space estimation, make the packaging tools aware of snapshots and handle them. Integrate Snapper management into Zypper.
If Btrfs can't be given better free-space estimation and it can't be given a reliably working repair tool, support other filesystems.
Handle ZFS and make sure the users know of the legalities. SUSE will not support ZFS and that is the company's choice, but testing on a ZFS basis could result in non-filesystem-dependent improvements to snapshot handling and package-manager support of snapshot space estimation.
Get involved with Stratis. Help make it work.
Get involved with bcachefs. Help make it work.
Or any 2 of those. Or all 3.
All of these will be expensive, but some solutions are needed. First, though, SUSE has to realise this is a problem. Currently it does not.
That is why I wrote about it. (Again.)