On 11/4/2021 10:32 AM, Darrick J. Wong wrote:

External email: Use caution opening links or attachments


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

quoted

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. ;)

Yes, it is not possible without a new interface and impossible for dm
and friends.

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

As part of a complete picture we once we get the block layer part stable
in the upstream how about implementing fsverify command like utility
that will work similar to fstrim so user can verify the critical files
with plumbing of VFS and iomap ?

Or is there other way that is more suitable ?

quoted

[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.