On Thu, Nov 04, 2021 at 09:27:50AM +0000, Chaitanya Kulkarni wrote:

On 11/4/2021 12:14 AM, Christoph Hellwig wrote:

quoted

External email: Use caution opening links or attachments


What is the actual use case here?

One of the immediate use-case is to use this interface with XFS 
scrubbing infrastructure [1] (by replacing any SCSI calls e.g. sg_io() 
with BLKVERIFY ioctl() calls corresponding to REQ_OP_VERIFY) and 
eventually allow and extend other file systems to use it for scrubbing.

FWIW it /would/ be a win to have a general blkdev ioctl to do this,
rather than shoving SCSI commands through /dev/sg, which (obviously)
doesn't work when dm and friends are in use.  I hadn't bothered to wire
up xfs_scrub to NVME COMPARE because none of my devices support it and
tbh I was holding out for this kind of interface anyway. ;)

I also wonder if it would be useful (since we're already having a
discussion elsewhere about data integrity syscalls for pmem) to be able
to call this sort of thing against files?  In which case we'd want
another preadv2 flag or something, and then plumb all that through the
vfs/iomap as needed?

--D

[1] man xfs_scrub :-
-x     Read all file data extents to look for disk errors.
               xfs_scrub will issue O_DIRECT reads to the block device
               directly.  If the block device is a SCSI disk, it will
               instead issue READ VERIFY commands directly to the disk.
               If media errors are found, the error report will include
               the disk offset, in bytes.  If the media errors affect a
               file, the report will also include the inode number and
               file offset, in bytes.  These actions will confirm that
               all file data blocks can be read from storage.