All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zdenek.kabelac@gmail.com>
To: dm-devel@redhat.com
Cc: Demi Marie Obenour <demi@invisiblethingslab.com>
Subject: Re: [dm-devel] Potential enhancements to dm-thin v2
Date: Wed, 13 Apr 2022 09:55:00 +0200	[thread overview]
Message-ID: <cebf10ca-ccf6-0809-dcff-3634817d8a5e@gmail.com> (raw)
In-Reply-To: <20220412142905.GA26912@redhat.com>

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.

So it's in the principle the very same case as the request for support of 
managing DM devices with 'external' metadata - if there are different 
constrains to match - you end with different requirements on the tool.

If there is pure focus on thin device management - surely a standalone tool 
does this jobs faster.


Zdenek

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

  reply	other threads:[~2022-04-13  7:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-10 22:03 [dm-devel] Potential enhancements to dm-thin v2 Demi Marie Obenour
2022-04-11  8:16 ` Zdenek Kabelac
2022-04-11 17:22   ` Demi Marie Obenour
2022-04-11 20:16     ` Zdenek Kabelac
2022-04-11 22:30       ` Demi Marie Obenour
2022-04-12  9:32         ` Zdenek Kabelac
2022-04-12 11:58           ` Demi Marie Obenour
2022-04-12 14:29           ` David Teigland
2022-04-13  7:55             ` Zdenek Kabelac [this message]
2022-04-13 15:00               ` Demi Marie Obenour

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cebf10ca-ccf6-0809-dcff-3634817d8a5e@gmail.com \
    --to=zdenek.kabelac@gmail.com \
    --cc=demi@invisiblethingslab.com \
    --cc=dm-devel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.