[pve-devel] [RFC 1/2 pve-storage] implement map_volume and unmap_volume

[Fabian Grünbichler]

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[1], 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..