[dm-devel] [announce] thin-provisioning-tools v1.0.0-rc1

[Joe Thornber]

Hi Eric,

On Fri, Mar 3, 2023 at 9:21 PM Eric Wheeler <dm-devel at lists.ewheeler.net>
wrote:

>
> It would be nice to get people testing the new improvements:
>
> Do you think it can make it for the 6.3 merge window that is open?
>

Doubtful.  The bulk of the changes are in dm-bufio, which is used by a lot
of targets.  So
I want to do a lot more testing before pushing upstream.



> Did thinp v2 get dropped, or just turn into the patchset above?
>
>
I've shelved thinp v2 in favour of userland approach I outlined.

 > I think io_uring, and ublk have shown us that this is viable.  That way

> > a snapshot copy-on-write, or dm-cache data migration, which are very
> > slow operations can be done with ordinary userland code.
>
> Would be nice to minimize CoW latency somehow if going to userspace
> increases that a notable amount.  CoW for spinning disks is definitely
> slow, but NVMe's are pretty quick to copy a 64k chunk.
>

Yes, minimising latency would be good.  I don't mind performing the CoW
within kernel, but I don't want to
handle the metadata updates in kernel.


> > For the fast paths, layering will be removed by having userland give
> > the kernel instruction to execute for specific regions of the virtual
> > device (ie. remap to here).
>
> Maybe you just answered my question of latency?
>

Yep.


>
> > The kernel driver will have nothing specific to thin/cache etc. I'm not
> > sure how many of the current dm-targets would fit into this model, but
> > I'm sure thin provisioning, caching, linear, and stripe can.
>
> To be clear, linear and stripe would stay in the kernel?


Linear and stripe would not need a call out to userland to service.  And
very little of thin/cache io would either.

 - Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20230306/af268aaf/attachment.htm>