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. Indeed. > To > 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 > warranted... 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 again.. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
