[dm-devel] Potential enhancements to dm-thin v2

[Demi Marie Obenour]

On Wed, Apr 13, 2022 at 09:55:00AM +0200, Zdenek Kabelac wrote:
> Dne 12. 04. 22 v 16:29 David Teigland napsal(a):
> > Dne 11. 04. 22 v 0:03 Demi Marie Obenour napsal(a):
> > > For quite a while, I have wanted to write a tool to manage thin volumes
> > > that is not based on LVM.
> > 
> > On Tue, Apr 12, 2022 at 11:32:09AM +0200, Zdenek Kabelac wrote:
> > > Here is actually the fundamental problem with your proposal - our design was
> > > about careful split between user-space and kernel 'who is the owner/holder
> > > of information'  - your proposal unfortunately does not fit the model where
> > > lvm2 is the authoritative owner of info about devices
> > 
> > The proposal is a new tool to manage dm-thin devices, not to rewrite lvm.
> > I would hope the tool is nothing at all like lvm, but rather "thinsetup"
> > in the tradition of dmsetup, cryptsetup.  I think it's a great idea and
> > have wanted such a tool for years.  I have a feeling that many have
> > already written ad hoc thinsetup-like tools, and there would be fairly
> > broad interest in it (especially if it has a proper lib api.)
> > 
> 
> 
> The problem with these 'ad-hoc' tools is their 'support - aka how to proceed
> in case of any failure.
> 
> So while there will be no problem to generate many device in very fast way -
> the recoverability from failure will then be always individual based on the
> surrounding environment.

That’s why I want to stick a name and UUID in each thin device’s
metadata.  That makes creating a thin device and associating it with a
name an atomic operation, and means that if there is a failure, the
sysadmin or management toolstack knows what it needs to do to clean up.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20220413/99d9f032/attachment.sig>