Re: [PATCH 2/2] xfs_check: process sparse inode chunks correctly

[Dave Chinner <david@fromorbit.com>]

On Tue, Jun 21, 2016 at 08:54:04AM -0500, Eric Sandeen wrote:
> 
> 
> On 6/21/16 4:01 AM, Carlos Maiolino wrote:
> > On Mon, Jun 20, 2016 at 12:52:42PM -0400, Brian Foster wrote:
> >> Update the inode btree scanning functions to process sparse inode chunks
> >> correctly. For filesystems with sparse inode support enabled, process
> >> each chunk a cluster at a time. Each cluster is checked against the
> >> inobt record to determine if it is a hole and skipped if so.
> >>
> >> Note that since xfs_check is deprecated in favor of xfs_repair,  this
> >> adds the minimum support necessary to process sparse inode enabled
> >> filesystems. In other words, this adds no sparse inode specific checks
> >> or verifications. We only update the inobt scanning functions to extend
> >> the existing level of verification to sparse inode enabled filesystems
> >> (e.g., avoid incorrectly tracking sparse regions as inodes). Problems
> >> or corruptions associated with sparse inode records must be detected and
> >> recovered via xfs_repair.
> >>
> > 
> > Hi,
> > 
> > I'm not quite sure, but a while ago, I thought I've heard some rumors about
> > deprecating xfs_check, is this true or something that my mind made up for some
> > weird reason?
> 
> Yes, like Brian said above.  ;)
> 
> bfc541e xfsprogs: remove xfs_check
> 12a48f5 xfsprogs: remove xfs_check references from fsck.xfs script & manpage
> 
> However, we still run check inside xfs_db in xfstests as an independent
> verification step:
> 
> 187bccd xfstests: Remove dependence of xfs_check script
> 
> +# xfs_check script is planned to be deprecated. But, we want to
> +# be able to invoke "xfs_check" behavior in xfstests in order to
> +# maintain the current verification levels.
> +_xfs_check()

Right - it's a secondary set of code that effectively tells us
whether repair is detecting all the problems it should. i.e. if
check fails and repair doesn't, then we've got a bug in repair that
needs fixing.

Also, the check code is really just an "addon" to other
functionality in xfs_db (e.g. blockget) that we have to keep, so
removing check doesn't really gain us all that much in terms of
reduced maintenance overhead. So long as we can easily keep check up
to date with new features I think we shoul dbe keeping it...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs