Hi Eric,
On Fri, Mar 3, 2023 at 9:21 PM Eric Wheeler <dm-devel@xxxxxxxxxxxxxxxxxx> 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
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
