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