On Thu, Nov 04, 2021 at 09:27:50AM +0000, Chaitanya Kulkarni wrote: > On 11/4/2021 12:14 AM, Christoph Hellwig wrote: > > 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. > >
