COW/noCOW on MicroOS Desktop /home subvolume
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 <Ah, but flatpaks takes a lot of space on disk!>> :-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? Also, while there, shall we evaluate adding other flags by default (i.e., things like autodefrag, or even compression itself)? 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 Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
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 <Ah, but flatpaks takes a lot of space on disk!>> :-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 And in KDE there's database-like tools like akondi (sp?) with its datastore in /home
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.
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
Regards _______________________________________________ openSUSE Kubic mailing list -- kubic@lists.opensuse.org To unsubscribe, email kubic-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/kubic@lists.opensuse.org
-- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
On Tue, Jan 5, 2021 at 9:41 AM Richard Brown <rbrown@suse.de> 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 <Ah, but flatpaks takes a lot of space on disk!>> :-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.:
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 Tue, 2021-01-05 at 09:56 -0500, Neal Gompa wrote:
On Tue, Jan 5, 2021 at 9:41 AM Richard Brown <rbrown@suse.de> wrote:
On Mon, 2020-12-21 at 19:06 +0100, Dario Faggioli wrote:
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
Exactly! That was what I had in mind when we had that discussion, and why I also though nocow for /home as a whole would be good.
However, as Neal says...
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.
... This is already covered :-) 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`. But, really, we don't even need to do that.
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...
Ok, this is something I personally have no experience or idea... I'd think that what I said above (i.e., one can go in the proper place and do +C, if having issues... And of course we can document that) applies here to, but I'm open to opinions and suggesions. About the rest, I agree with Richard, that applies to openSUSE as a whole, so let's discuss the two things separately. Thanks, Regards and Happy New Year! :-D -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
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 <rbrown@suse.de> 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/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
participants (3)
-
Dario Faggioli -
Neal Gompa -
Richard Brown