xfs
[Top] [All Lists]

Re: [PATCH v3 3/7] xfs: cap prealloc size to free space before shift

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH v3 3/7] xfs: cap prealloc size to free space before shift
From: Brian Foster <bfoster@xxxxxxxxxx>
Date: Wed, 20 Feb 2013 08:17:53 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130219231954.GI10731@dastard>
References: <1361291851-24714-1-git-send-email-bfoster@xxxxxxxxxx> <1361291851-24714-4-git-send-email-bfoster@xxxxxxxxxx> <20130219214842.GG10731@dastard> <5123FCB7.9050309@xxxxxxxxxx> <20130219231954.GI10731@dastard>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2
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.
> 

<Prev in Thread] Current Thread [Next in Thread>