On Wed, Jan 10, 2024 at 05:42:04PM -0800, Darrick J. Wong wrote: > On Tue, Jan 09, 2024 at 05:38:16PM +1100, Dave Chinner wrote: > > On Mon, Jan 08, 2024 at 10:14:42PM -0800, Darrick J. Wong wrote: > > > In that case, perhaps it makes more sense to have > > > xfs_trans_dqresv return an unusual errno for "project quota over limits" > > > so that callers can trap that magic value and translate it into ENOSPC? > > > > Sure, that's another option, but it means we have to trap EDQUOT, > > ENOSPC and the new special EDQUOT-but-really-means-ENOSPC return > > errors. I'm not sure it will improve the code a great deal, but if > > there's a clean way to implement such error handling it may make > > more sense. Have you prototyped how such error handling would look > > in these cases? > > > > Which also makes me wonder if we should actually be returning what > > quota limit failed, not EDQUOT. To take the correct flush action, we > > really need to know if we failed on data blocks, inode count or rt > > extents. e.g. flushing data won't help alleviate an inode count > > overrun... > > Yeah. If it's an rtbcount, then it only makes sense to flush realtime > files; if it's a bcount, we flush nonrt files, and if it's an inode > count then I guess we push inodegc? Yes, that sounds like a reasonable set of actions to take for the different failure modes. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
