Re: [PATCH 11/11] xfs: add media error reporting ioctl

["Darrick J. Wong" <djwong@kernel.org>]

On Thu, Jan 08, 2026 at 05:14:04PM +0100, Christoph Hellwig wrote:
> On Thu, Jan 08, 2026 at 08:09:29AM -0800, Darrick J. Wong wrote:
> > But maybe the blockdev fs can implement the new fserror hook, see if
> > there's a super_block associated with the bdev, and throw the fserror
> > up to the mounted filesystem.
> > 
> > (Hard part: partitions)
> 
> All the partition mapping can be trivially undone.  I still think
> issuing the commands on the block device instead of from the file
> system feels wrong.

"From the filesystem"?  That gives me an idea: what if xfs_scrub instead
opens the root dir, calls an ioctl that does the verify work, and that
ioctl then reports the result to userspace and xfs_healthmon?

As opposed to this kind of stupid reporting ioctl?

> > > > Or I guess one of us should go figure out a reasonable verify command
> > > > that would call fserror_* on media errors.
> > > 
> > > Hmm, I would expect the verify command to be issued by fs/xfs/scrub/
> > > in the kernel, so that it can be directly tied into the in-kernel
> > > logical to physical and rmap.  But you are more well versed there,
> > > so maybe I'm missing something.
> > 
> > Did Chaitanya actually push for the verify command to get merged?
> 
> Not yet.
> 
> > I guess it wouldn't be terribly hard to make a stupid version that
> > simply does direct reads to a throwaway page, to work around willy's
> > objection that the existing scsi verify command doesn't require proof
> > that the device actually did anything (and some of them clearly don't).
> 
> We could do that, although I'd make it conditional.  For the kind of
> storage you want to store your data on it does work, as the customer
> would get very unhappy otherwise.

Heheh.  It's really too bad that I have a bunch of Very Expensive RAID
controllers that lie... and it's the crappy Samsung QVO SSDs that
actually do the work.

--D