On Wed, May 28, 2014 at 07:26:53AM +1000, Dave Chinner wrote:
> > Right... maybe I'm not parsing your point. The purpose here is to avoid
> > the trylock entirely. E.g., Indicate that we have already acquired the
> > lock and can proceed with xfs_free_eofblocks(), rather than fail a
> > trylock and skip (which appears to be a potential infinite loop scenario
> > here due to how the AG walking code handles EAGAIN).
> I think Christoph's concern here is that we are calling a function
> that can take the iolock while we already hold the iolock. i.e. the
> reason we have to add the anti-deadlock code in the first place.
> address that, can we restructure xfs_file_buffered_aio_write() such
> that the ENOSPC/EDQUOT flush is done outside the iolock?
> >From a quick check, I don't think there is any problem with dropping
> the iolock, doing the flushes and then going all the way back to the
> start of the function again, but closer examination and testing is
I think we'd need some form of early space reservation, otherwise we'd
get non-atomic writes. Time to get those batches write patches out