[pve-devel] [RFC 1/2 pve-storage] implement map_volume and unmap_volume
f.gruenbichler at proxmox.com
Fri Sep 21 19:58:23 CEST 2018
On Fri, Sep 21, 2018 at 03:21:50PM +0200, Dietmar Maurer wrote:
> > I know you just do this to not duplicate the blockdevice path assembly,
> > but it feels a bit weird to directly have an map with $nomap method call
> > in unmap, maybe pull the common parts out in its own ($private) helper sub?
> I though somebody will suggest a better name for that parameter so that it looks more reasonable?
FWIW, I like Thomas suggestion of pulling out the bdev path generation
into a private sub (or, since we are already adding to the storage
API, evaluate whether "give me the block device for this volume"
deserves its own API method).
are there other storage types/situations where map would be appropriate?
IMHO, LVM and LVM-Thin would logically also fit into that category
(especially if we ever implement using the "activation skip" feature for
PVE-managed LVs, and not let them auto-activate on boot anymore).
loopback devices (.raw / .iso for containers) might also work, but the
current code is a bit more involved so might not be easily portable to
the new map_volume semantics..
1: don't forget to bump the storage plugin API version..
More information about the pve-devel