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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
