On 27/06/2025 10:14, Fabian Grünbichler wrote: > >> Friedrich Weber <f.we...@proxmox.com> hat am 23.06.2025 11:25 CEST >> geschrieben: >> >> >> On 10/06/2025 17:00, Michael Köppl wrote: >>> On 4/29/25 13:36, Friedrich Weber wrote: >>>> When discovering a new volume group (VG), for example on boot, LVM >>>> triggers autoactivation. With the default settings, this activates all >>>> logical volumes (LVs) in the VG. Activating an LV creates a >>>> device-mapper device and a block device under /dev/mapper. >>>> >>>> Autoactivation is problematic for shared LVM storages, see #4997 [1]. >>>> For the inherently local LVM-thin storage it is less problematic, but >>>> it still makes sense to avoid unnecessarily activating LVs and thus >>>> making them visible on the host at boot. >>>> >>>> Hence, disable autoactivation after creating new LVs. As lvcreate >>>> doesn't accept the --setautoactivation flag for thin LVs, this is done >>>> with an additional lvchange command. With this setting, LVM >>>> autoactivation will not activate these LVs, and the storage stack will >>>> take care of activating/deactivating LVs when needed. >>>> >>>> [1] https://bugzilla.proxmox.com/show_bug.cgi?id=4997 >>>> >>>> Signed-off-by: Friedrich Weber <f.we...@proxmox.com> >>>> --- >>>> >>>> Notes: >>>> - would be great to get your opinion on whether we should consider >>>> LVM-thin storages in this series or not. >>>> >>>> - passing --setautoactivation n to lvcreate for a thin volume says: >>>> >>>> Option --setautoactivation is unsupported with thins. >>>> >>>> But lvchange --setautoactivation seems to work on thin LVs, so the >>>> fact that lvcreate doesn't accept it may be a bug. I reported it >>>> upstream [1]. >>>> >>>> new in v3 >>>> >>>> [1] https://gitlab.com/lvmteam/lvm2/-/issues/32 >>> >>> Since the upstream issue has not been addressed yet and the change to >>> LVM-thin does, AFAICT, not mitigate problems like in #4997 (or am I >>> missing something here?), but is mostly done to streamline behavior, >>> could the changes for LVM-thin be held back until it's clear that >>> lvcreate not supporting --setautoactivation for LVM-thin is not on purpose? >> >> Good point. I agree disabling autoactivation isn't as important for >> LVM-thin as it is for LVM-thick, though it's preferable also here that >> VM disks are not always active on the host, but only activated on-demand >> by our storage stack. >> >> From looking at the lvm2 commit introducing `--setautoactivation` [1] >> the omission of --setautoactivation for thin LVs doesn't seem >> intentional to me (maybe it was just forgotten to add to >> LVCREATE_ARGS?), but I can't be 100% sure either. >> >> The problem with holding back the change for LVM-thin is that we also >> need a way to update already-existing LVs, and the 8->9 bump is a good >> opportunity to do so via pve8to9. >> >> @Fabian, what do you think? > > it seems very likely this was by accident, and not by design. > > maybe opening an MR fixing it in addition to the issue gets > more upstream attention?
Good point, thanks. I opened a MR upstream: https://gitlab.com/lvmteam/lvm2/-/merge_requests/31 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
