On Mon, May 18, 2020 at 10:01:12AM -0700, Christoph Hellwig wrote: > On Mon, May 18, 2020 at 08:34:54AM -0400, Brian Foster wrote: > > Christoph's comment aside, note that the quota helpers here are filtered > > scans based on the dquots attached to the inode. It's basically an > > optimized scan when we know the failure was due to quota, so I don't > > think there should ever be a need to run a quota scan after running the > > -ENOSPC handling above. For project quota, it might make more sense to > > check if a pdquot is attached, check xfs_dquot_lowsp() and conditionally > > update the eofb to do a filtered pquota scan if appropriate (since > > calling the quota helper above would also affect other dquots attached > > to the inode, which I don't think we want to do). Then we can fall back > > to the global scan if the pquota optimization is not relevant or still > > returns -ENOSPC on the subsequent retry. > > That's what I've implemented. But it turns out -ENOSPC can of course > still mean a real -ENOSPC even with project quotas attached. So back > to the drawing board - I think I basically need to replace the enospc > with a tristate saying what kind of scan we've tried. Or we just ignore > the issue and keep the current global scan after a potential project > quota -ENOSPC, because all that cruft isn't worth it after all. > Sure, that's why I was suggesting to check the quota for low free space conditions. One one hand, a quota scan might be worth it under low quota space conditions to avoid the heavy handed impact (i.e. flush everything) on an fs that otherwise might have plenty of free space. OTOH, it might be pointless if permanent -ENOSPC (due to project quota) is imminent and we always fall back to the global scan. Brian
