On Tue, Apr 26, 2022 at 05:45:03PM -0700, Darrick J. Wong wrote: > On Wed, Apr 27, 2022 at 09:44:50AM +1000, Dave Chinner wrote: > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > Sean Caron reported that a metadump terminated after givin gthis > > warning: > > > > xfs_metadump: inode 2216156864 has unexpected extents > > > > Metadump is supposed to ignore corruptions and continue dumping the > > filesystem as best it can. Whilst it warns about many situations > > where it can't fully dump structures, it should stop processing that > > structure and continue with the next one until the entire filesystem > > has been processed. > > > > Unfortunately, some warning conditions also return an "abort" error > > status, causing metadump to abort if that condition is hit. Most of > > these abort conditions should really be "continue on next object" > > conditions so that the we attempt to dump the rest of the > > filesystem. > > > > Fix the returns for warnings that incorrectly cause aborts > > such that the only abort conditions are read errors when > > "stop-on-read-error" semantics are specified. Also make the return > > values consistently mean abort/continue rather than returning -errno > > to mean "stop because read error" and then trying to infer what > > the error means in callers without the context it occurred in. > > I was almost about to say "This variable should be named success", but > then noticed that there already /are/ variables named success. Yuck. Yeah, mess. > rval==0 means abort? and rval!=0 means continue? If so, Same as it was before. > Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx> Ta. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
