Re: [RFC PATCH 08/13] xfs: parent pointer attribute creation

[Dave Chinner <david@fromorbit.com>]

On Mon, Aug 14, 2017 at 05:06:06PM -0700, Darrick J. Wong wrote:
> On Wed, Aug 09, 2017 at 06:41:28PM -0700, Allison Henderson wrote:
> > +	/* Try to add the attr to the attribute list in the inode. */
> > +	xfs_attr_shortform_create(&args);
> > +	error = xfs_attr_shortform_addname(&args);
> > +	if (error != -ENOSPC)
> > +		return error;
> 
> I wonder, what happens if we exceed the maximum number of attr fork
> extents by linking a file too many times?

We'll hit free space indexing scalability problems with the dir1
format used by the attr tree before we get there. And to solve that
we simply convert the attr code to use the dir3 format tree....

> Would be nice if we could
> bail out early (instead of shutting down the fs) if we were reasonably
> sure it was going to blow up anyway.
> 
> Though, I'm wondering how we handle that in general since I don't see
> any obvious checking...
> 
> Also seems a little fishy that we keep going even if ENOSPC, even though
> the comment below says we're allowed to dip into the reserved space to
> avoid this condition?

When I wrote this, we had a small, fixed reserve pool that could be
depleted by excessive operation at ENOSPC conditions, and hence
ENOSPC could still occur (however unlikely it might be).

Once again, the reserve pool is very different now, so the
assumptions this code makes about ENOSPC behaviour might not be
valid anymore...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com