On 8/22/25 10:21 AM, Darrick J. Wong wrote: > On Thu, Aug 21, 2025 at 04:36:10PM -0500, Eric Sandeen wrote: ... >> diff --git a/fs/xfs/libxfs/xfs_attr_leaf.c b/fs/xfs/libxfs/xfs_attr_leaf.c >> index fddb55605e0c..9b54cfb0e13d 100644 >> --- a/fs/xfs/libxfs/xfs_attr_leaf.c >> +++ b/fs/xfs/libxfs/xfs_attr_leaf.c >> @@ -478,6 +478,12 @@ xfs_attr3_leaf_read( >> >> err = xfs_da_read_buf(tp, dp, bno, 0, bpp, XFS_ATTR_FORK, >> &xfs_attr3_leaf_buf_ops); >> + /* >> + * ENODATA from disk implies a disk medium failure; ENODATA for >> + * xattrs means attribute not found, so disambiguate that here. >> + */ >> + if (err == -ENODATA) >> + err = -EIO; > > I think this first chunk isn't needed since you also changed > xfs_da_read_buf to filter the error code, right? Doh, yeah, I guess I got tunnel vision on that, sorry. I should have caught that. > (Shifting towards the giant reconsideration of ENODATA -> EIO filtering) > > Do we now also need to adjust the online fsck code to turn ENODATA into > a corruption report? From __xchk_process_error: > > case -EFSBADCRC: > case -EFSCORRUPTED: > /* Note the badness but don't abort. */ > sc->sm->sm_flags |= errflag; > *error = 0; > fallthrough; > default: > trace_xchk_op_error(sc, agno, bno, *error, ret_ip); > break; > } > > We only flag corruptions for these two error codes, but ENODATA from the > block layer means "critical medium error". I take that to mean the > media has permanently lost whatever was persisted there, right? I assume so - I guess it's "corruption in absentia?" I could imagine EIO indicating a similar "data is gone, sorry" problem too, though. I honestly don't know what EIO or ENODATA or any other errors from the block layer mean in detail, or how consistent errors are across device types etc. -Eric > --D
