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@xxxxxxxxxxxxx > -- Carlos _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
