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: >> 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. ;) > 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 ? >> [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. >> >>
