On 2022/05/02 13:09, Dave Chinner wrote: > 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... That is a very good idea ! But that will cover only the non-zoned case. For copy offload on zoned devices, adding support in null_blk is probably the simplest thing to do. > > i.e. I think you're doing this compeltely backwards by trying to > target non-existent hardware first.... > > Cheers, > > Dave. -- Damien Le Moal Western Digital Research
