On 02/19/2013 06:19 PM, Dave Chinner wrote: > On Tue, Feb 19, 2013 at 05:29:11PM -0500, Brian Foster wrote: >> On 02/19/2013 04:48 PM, Dave Chinner wrote: >>> On Tue, Feb 19, 2013 at 11:37:27AM -0500, Brian Foster wrote: ... >> Tracking back to that discussion... >> >> http://oss.sgi.com/archives/xfs/2013-01/msg00392.html >> >> ... my understanding is that at the moment, the condition addressed by >> the previous change is not relevant to quota since we have no >> flush/retry cycle (e.g., we just fail early). The intended follow up set >> to this (eofblocks scan, retry) would introduce such a cycle. What I'm >> wondering is if we'll need something similar longer term within the >> quota throttling code. > > There is a retry cycle for EDQUOT - we simply turn off preallocation > and try again. So, if we ask for all the free blocks in the > quota.... > >> >> In particular, is the "metadata overhead" referred to in your original >> explanation accounted against an associated quota, > > ... this *may* trigger an EDQUOT and turn off preallocation. > Good point. I guess I was more thinking about the severity of the effective "sync write" mode caused by the flush and retry cycle, as opposed to the loss of prealloc and hit of the retry. The eofblocks scan shouldn't be as heavy weight as a flush, but that kind of cycle is undesirable nonetheless. >> such that it still >> isn't enough to simply start the prealloc capped at the quota free space >> limit? If so, perhaps as part of that set I'll need to modify this code >> to carry a minimum 'qfreesp' through each of the quotas and add that to >> the squashing loop... > > Probably. > > i.e. it doesn't matter alloc_blocks is over freesp or dquot limits > at the end of the prealloc size calculation. If it is, we just keep > squashing it by >>= 4 until it is under all relevant thresholds... > Yeah, that's pretty much what I was thinking. I'll plan to include that as part of the follow on work that introduces the eofblocks scan. Thanks. Brian > Cheers, > > Dave. > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
