From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Zdenek Kabelac <zdenek.kabelac@gmail.com>, dm-devel@redhat.com
Subject: Re: [dm-devel] Potential enhancements to dm-thin v2
Date: Wed, 13 Apr 2022 11:00:53 -0400 [thread overview]
Message-ID: <YlblqqmQCdJ9jZWh@itl-email> (raw)
In-Reply-To: <cebf10ca-ccf6-0809-dcff-3634817d8a5e@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1802 bytes --]
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
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 98 bytes --]
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
prev parent reply other threads:[~2022-04-14 11:17 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
2022-04-13 15:00 ` Demi Marie Obenour [this message]
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=YlblqqmQCdJ9jZWh@itl-email \
--to=demi@invisiblethingslab.com \
--cc=dm-devel@redhat.com \
--cc=zdenek.kabelac@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox