On Wed, Jun 22, 2016 at 10:03:24AM +0200, Carlos Maiolino wrote: > 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? I have, while writing reflink. Granted, that only happened /once/. While we're talking about repair/xfstests, I also started running xfs_repair and then xfs_repair -n to _check_xfs_filesystem, which helped me find some cases where the rmapbt rebuild wasn't quite right. --D > > > 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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
