On Wed, Apr 27, 2022 at 06:19:51PM +0530, Nitesh Shetty wrote: > O Wed, Apr 27, 2022 at 11:19:48AM +0900, Damien Le Moal wrote: > > On 4/26/22 19:12, Nitesh Shetty wrote: > > > The patch series covers the points discussed in November 2021 virtual call > > > [LSF/MM/BFP TOPIC] Storage: Copy Offload[0]. > > > We have covered the Initial agreed requirements in this patchset. > > > Patchset borrows Mikulas's token based approach for 2 bdev > > > implementation. > > > > > > Overall series supports – > > > > > > 1. Driver > > > - NVMe Copy command (single NS), including support in nvme-target (for > > > block and file backend) > > > > It would also be nice to have copy offload emulation in null_blk for testing. > > > > We can plan this in next phase of copy support, once this series settles down. Why not just hook the loopback driver up to copy_file_range() so that the backend filesystem can just reflink copy the ranges being passed? That would enable testing on btrfs, XFS and NFSv4.2 hosted image files without needing any special block device setup at all... i.e. I think you're doing this compeltely backwards by trying to target non-existent hardware first.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel