Re: [PATCH] xfs: do not propagate ENODATA disk errors into xattr code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 25, 2025 at 08:34:14AM -0700, Darrick J. Wong wrote:
> > +	case BLK_STS_NOSPC:
> > +		return -ENOSPC;
> > +	case BLK_STS_OFFLINE:
> > +		return -ENODEV;
> > +	default:
> > +		return -EIO;
> 
> Well as I pointed out earlier, one interesting "quality" of the current
> behavior is that online fsck captures the ENODATA and turns that into a
> metadata corruption report.  I'd like to keep that behavior.

-EIO is just as much of a metadata corruption, so if you only catch
ENODATA you're missing most of them.

> >  	if (bio->bi_status)
> > -		xfs_buf_ioerror(bp, blk_status_to_errno(bio->bi_status));
> > +		xfs_buf_ioerror(bp, xfs_buf_bio_status(bio));
> 
> I think you'd also want to wrap all the submit_bio_wait here too, right?
> 
> Hrm, only discard bios, log writes, and zonegc use that function.  Maybe
> not?  I think a failed log write takes down the system no matter what
> error code, nobody cares about failing discard, and I think zonegc write
> failures just lead to the gc ... aborting?

Yes.  In Linux -EIO means an unrecoverable I/O error that the lower
layers gave up retrying. Not much we can do about that.





[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux