On Tue, Jan 5, 2021 at 9:41 AM Richard Brown wrote:

On Mon, 2020-12-21 at 19:06 +0100, Dario Faggioli wrote:

...

Hello,

I've finally had the chance to put in a VM an instance of MicroOS Desktop with the new partition layout and. IMO, the fact that it has /var in a (nocow) subvolume is really a big improvement, so thanks Richard for that!

We have /home in a subvolume too, which is also great, and it as well has the nocow flag set. I know this mostly come from a conversation we had on #microos-desktop on IRC but thinking more about that, and discussing this with some users, I wonder whether it is really the best choice.

I mean, it sure is ok for /var, but for /home, using nocow means that we give up on some of the nicer BTRFS features, especially for home folders, wouldn't it?

That might be especially true for MicroOS Desktop. E.g., think at being able to compress (if not the entire home directories or the entire subvolume) the user installed flatpaks (and using that as an argument "against" those that are still complaining that > :-D).

So, are there reasons why it's really preferable to keep the /home subvolume as nocow and I'm missing them? Or shall we switch it to cow?

There's one, which is the main reason I did it in the first place

GNOME Boxes (IMHO the best virtualisation tool) or virt-manager User Sessions puts qcow2 VM images in /home

libvirt, since 6.7.0, automatically provisions storage pools on btrfs with nodatacow by default. This obviates the need to have /home as nodatacow by default.

And in KDE there's database-like tools like akondi (sp?) with its datastore in /home

I don't think Akonadi does anything special when initializing its datastore on Btrfs, though I personally haven't worried about it either...

...

Also, while there, shall we evaluate adding other flags by default (i.e., things like autodefrag, or even compression itself)?

This is an interesting idea - but I'd rather we consider what makes sense for all of openSUSE there. I dont see MicroOS Desktop really bringing in unique requirements when it comes to autodefrag or compression.

There's been some discussion in Fedora about autodefrag: https://pagure.io/fedora-btrfs/project/issue/16 The issue right now is that the autodetection of applicability of autodefrag isn't reliable enough. :(

...

E.g., AFAIUI, on Fedora, while not doing that right now, they're considering doing something like that, e.g.:

https://pagure.io/fedora-btrfs/project/issue/5

I'm expecting Fedora to implement it. The Change has been submitted for review, and I don't expect it to be controversial. -- 真実はいつも一つ！/ Always, there's only one truth!

On Wed, 2021-01-06 at 13:05 +0100, Dario Faggioli wrote:

On Tue, 2021-01-05 at 09:56 -0500, Neal Gompa wrote:

...

On Tue, Jan 5, 2021 at 9:41 AM Richard Brown wrote:

...

GNOME Boxes (IMHO the best virtualisation tool) or virt-manager User Sessions puts qcow2 VM images in /home

libvirt, since 6.7.0, automatically provisions storage pools on btrfs with nodatacow by default. This obviates the need to have /home as nodatacow by default.

So, I finally double checked this.

GNOME Boxes on flathub is still on libvirt 6.1.0, but on flathub-beta, version 40 is on libvirt 6.7.0, which means this will (hopefully) soon be covered for everyone, just by default. Plus, I continue to think that this holds:

And, thinking more about it, it's probably the case that having advanced features (like compression, etc) for _everything_in_home_ would be worth the hassle of going to the place where Boxes stores disk images and do a `chattr`.

And finally, in Tumbleweed (and maybe even Leap? I can't remember what we do in 15.2/didn't check what we do in 15.3), when we propose to keep /home in a subvolume, that is COW, isn't it? So, I went ahead, and created this: https://github.com/yast/skelcd-control-MicroOS/pull/32 Feedback (and reviews) welcome. :-) Thanks and Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <> (Raistlin Majere)