Re: [PATCH 1/6] xfs: use XFS_IFORK_BOFF xchk_bmap_check_rmaps

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Tue, May 12, 2020 at 12:14:10PM -0400, Brian Foster wrote:
> On Tue, May 12, 2020 at 08:38:54AM -0700, Darrick J. Wong wrote:
> > On Tue, May 12, 2020 at 11:31:32AM -0400, Brian Foster wrote:
> > > On Mon, May 11, 2020 at 05:10:04PM +0530, Chandan Babu R wrote:
> > > > On Sunday 10 May 2020 12:53:59 PM IST Christoph Hellwig wrote:
> > > > > XFS_IFORK_Q is to be used in boolean context, not for a size.  This
> > > > > doesn't make a difference in practice as size is only checked for
> > > > > 0, but this keeps the logic sane.
> > > > >
> > > > 
> > > > Wouldn't XFS_IFORK_ASIZE() be a better fit since it gives the space used by the
> > > > attr fork inside an inode's literal area?
> > > > 
> > > 
> > > I had the same thought. It's not clear to me what size is really
> > > supposed to be between the file size for a data fork and fork offset for
> > > the attr fork. I was also wondering if this should use
> > > XFS_IFORK_DSIZE(), but that won't be conditional based on population of
> > > the fork. At the same time, I don't think i_size != 0 necessarily
> > > correlates with the existence of blocks. The file could be completely
> > > sparse or could have any number of post-eof preallocated extents.
> > 
> > TBH I should have made that variable "bool empty" or something.
> > 
> > case XFS_DATA_FORK:
> > 	empty = i_size_read() == 0;
> > 
> 
> Even that is somewhat unclear because it's tied to i_size. What about
> size == 0 && <post-eof extents>?

/me stumbles around trying to remember under what circumstances do we
actually scan all the rmaps to make sure there's a corresponding bmap.
I think we're trying to avoid doing it for every file in the filesystem
because it's very slow...

Oh right -- we do that for btree format forks because there are a lot of
extent records and therefore a high(er) chance of something getting
lost; or

We scan all the rmaps for files that have nonzero size but zero extents,
because the (forthcoming) inode fork repair will reset damaged forks
back to extents format with zero extents, and this is how we will
trigger the bmap repair to get the extents mapped back into the file.

--D

> 
> Brian
> 
> > case XFS_ATTR_FORK:
> > 	empty = !XFS_IFORK_Q();
> > 
> > default:
> > 	empty = true;
> > 
> > if ((is not btree) && (empty || nextents > 0))
> > 	return 0;
> > 
> > --D
> > 
> > > Brian
> > > 
> > > > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > > > > ---
> > > > >  fs/xfs/scrub/bmap.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/fs/xfs/scrub/bmap.c b/fs/xfs/scrub/bmap.c
> > > > > index add8598eacd5d..283424d6d2bb6 100644
> > > > > --- a/fs/xfs/scrub/bmap.c
> > > > > +++ b/fs/xfs/scrub/bmap.c
> > > > > @@ -591,7 +591,7 @@ xchk_bmap_check_rmaps(
> > > > >  		size = i_size_read(VFS_I(sc->ip));
> > > > >  		break;
> > > > >  	case XFS_ATTR_FORK:
> > > > > -		size = XFS_IFORK_Q(sc->ip);
> > > > > +		size = XFS_IFORK_BOFF(sc->ip);
> > > > >  		break;
> > > > >  	default:
> > > > >  		size = 0;
> > > > > 
> > > > 
> > > > 
> > > > -- 
> > > > chandan
> > > > 
> > > > 
> > > > 
> > > 
> > 
>