On Thu, Nov 07, 2019 at 02:46:21PM +1100, Dave Chinner wrote:
> On Wed, Nov 06, 2019 at 07:46:12AM -0800, Darrick J. Wong wrote:
> > On Wed, Nov 06, 2019 at 07:49:32AM -0500, Brian Foster wrote:
> > > > > /*
> > > > > + * Check whether the replace operation need more blocks.
> > > > > + */
> > > > > +bool
> > > > > +xfs_dir2_sf_replace_needblock(
> > > >
> > > > Urgggh. This is a predicate that we only ever call from xfs_rename(),
> > > > right? And it addresses a particular quirk of the locking when the
> > > > caller wants us to rename on top of an existing entry and drop the link
> > > > count of the old inode, right? So why can't this just be a predicate in
> > > > xfs_inode.c ? Nobody else needs to know this particular piece of
> > > > information, AFAICT.
> > > >
> > > > (Apologies, for Brian and I clearly aren't on the same page about
> > > > that...)
> > > >
> > >
> > > Hmm.. the crux of my feedback on the previous version was simply that if
> > > we wanted to take this approach of pulling up lower level dir logic into
> > > the higher level rename code, to simply factor out the existing checks
> > > down in the dir replace code that currently trigger a format conversion,
> > > and use that new helper in both places. That doesn't appear to be what
> > > this patch does, and I'm not sure why there are now two new helpers that
> > > each only have one caller instead of one new helper with two callers...
> >
> > Aha, got it. I'd wondered if that had been your intent. :)
>
> So as a structural question: should this be folded into
> xfs_dir_canenter(), which is the function used to check if the
> directory modification can go ahead without allocating blocks....
>
> This seems very much like it is a "do we need to allocate blocks
> during the directory modification?" sort of question being asked
> here...
>
I _think_ Kaixu brought this up briefly in looking at the previous
version of this patch. From a code standpoint, I agree that this path
seems like the most logical fit, but my understanding was that the
canenter thing is kind of an inconsistent and unreliable mechanism at
this point. IIRC, we've explicitly removed its use from the create path
to work around things like block reservation overruns leading to fs
shutdowns as opposed to digging into the mechanism and fixing whatever
accounting was broken. See commit f59cf5c299 ("xfs: remove
"no-allocation" reservations for file creations"), for example. I
believe the discussion around that patch basically concluded that the
complexity of maintaining/debugging the canenter path wasn't worth the
benefit of squeezing every last block out of the fs, but that was a
while ago now.
That aside, I don't have a strong opinion on the best way to fix this
particular deadlock problem. The only other thing (outside of
reliability) I might question with the canenter approach is whether it
has ever been used in situations outside of -ENOSPC, and if not, whether
there's any potential performance impact of invoking it more frequently.
Brian
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
