On Thu, Mar 28, 2024 at 05:16:54PM -0500, Eric Blake wrote: > On Thu, Mar 28, 2024 at 04:39:01PM -0400, Stefan Hajnoczi wrote: > > This can speed up the process by reducing the amount of data read and it > > preserves sparseness when writing to the output file. > > > > This patch series is an initial attempt at implementing > > llseek(SEEK_HOLE/SEEK_DATA) for block devices. I'm looking for feedback on this > > approach and suggestions for resolving the open issues. > > One of your open issues was whether adjusting the offset of the block > device itself should also adjust the file offset of the underlying > file (at least in the case of loopback and dm-linear). What would the Only the loop block driver has this issue. The dm-linear driver uses blkdev_seek_hole_data(), which does not update the file offset because it operates on a struct block_device instead of a struct file. > > > > > In the block device world there are similar concepts to holes: > > - SCSI has Logical Block Provisioning where the "mapped" state would be > > considered data and other states would be considered holes. > > BIG caveat here: the SCSI spec does not necessarily guarantee that > unmapped regions read as all zeroes; compare the difference between > FALLOC_FL_ZERO_RANGE and FALLOC_FL_PUNCH_HOLE. While lseek(SEEK_HOLE) > on a regular file guarantees that future read() in that hole will see > NUL bytes, I'm not sure whether we want to make that guarantee for > block devices. This may be yet another case where we might want to > add new SEEK_* constants to the *seek() family of functions that lets > the caller indicate whether they want offsets that are guaranteed to > read as zero, vs. merely offsets that are not allocated but may or may > not read as zero. Skipping unallocated portions, even when you don't > know if the contents reliably read as zero, is still a useful goal in > some userspace programs. SCSI initiators can check the Logical Block Provisioning Read Zeroes (LBPRZ) field to determine whether or not zeroes are guaranteed. The sd driver would only rely on the device when LPBRZ indicates that zeroes will be read. Otherwise the driver would report that the device is filled with data. > > > - NBD has NBD_CMD_BLOCK_STATUS for querying whether blocks are present. > > However, utilizing it in nbd.ko would require teaching the kernel to > handle structured or extended headers (right now, that is an extension > only supported in user-space implementations of the NBD protocol). I > can see why you did not tackle that in this RFC series, even though > you mention it in the cover letter. Yes, I'm mostly interested in dm-thin. The loop block driver and dm-linear are useful for testing so I modified them. I didn't try SCSI or NBD. Thanks, Stefan
Attachment:
signature.asc
Description: PGP signature
