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

[Carlos Maiolino <cmaiolino@redhat.com>]

On Wed, Jun 22, 2016 at 09:29:40AM +1000, Dave Chinner wrote:
> 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.
> 

Just out of curiosity here, have we hit any case like that for the past few
versions?

> 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...
> 

Good to know.

Cheers o/

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> 

-- 
Carlos

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