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
|