<div dir="ltr"><div>Hi Eric,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 3, 2023 at 9:21 PM Eric Wheeler <<a href="mailto:dm-devel@lists.ewheeler.net">dm-devel@lists.ewheeler.net</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It would be nice to get people testing the new improvements:<br>
<br>
Do you think it can make it for the 6.3 merge window that is open?<br></blockquote><div><br></div><div>Doubtful.  The bulk of the changes are in dm-bufio, which is used by a lot of targets.  So</div><div>I want to do a lot more testing before pushing upstream.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Did thinp v2 get dropped, or just turn into the patchset above?<br>
<br></blockquote><div><br></div><div>I've shelved thinp v2 in favour of userland approach I outlined.</div><div><br></div><div> > I think io_uring, and ublk have shown us that this is viable.  That way</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> a snapshot copy-on-write, or dm-cache data migration, which are very <br>
> slow operations can be done with ordinary userland code.<br>
<br>
Would be nice to minimize CoW latency somehow if going to userspace <br>
increases that a notable amount.  CoW for spinning disks is definitely <br>
slow, but NVMe's are pretty quick to copy a 64k chunk.<br></blockquote><div><br></div><div>Yes, minimising latency would be good.  I don't mind performing the CoW within kernel, but I don't want to</div><div>handle the metadata updates in kernel.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> For the fast paths, layering will be removed by having userland give<br>
> the kernel instruction to execute for specific regions of the virtual <br>
> device (ie. remap to here).<br>
<br>
Maybe you just answered my question of latency?<br></blockquote><div><br></div><div>Yep.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> The kernel driver will have nothing specific to thin/cache etc. I'm not <br>
> sure how many of the current dm-targets would fit into this model, but <br>
> I'm sure thin provisioning, caching, linear, and stripe can.<br>
<br>
To be clear, linear and stripe would stay in the kernel?</blockquote><div><br></div><div>Linear and stripe would not need a call out to userland to service.  And very little of thin/cache io would either.</div><div><br></div><div> - Joe<br></div></div></div>