From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH v3 3/7] xfs: cap prealloc size to free space before shift
Date: Wed, 20 Feb 2013 08:17:53 -0500 [thread overview]
Message-ID: <5124CD01.1050602@redhat.com> (raw)
In-Reply-To: <20130219231954.GI10731@dastard>
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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-02-20 13:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-19 16:37 [PATCH v3 0/7] speculative preallocation quota throttling Brian Foster
2013-02-19 16:37 ` [PATCH v3 1/7] xfs: reorganize xfs_iomap_prealloc_size to remove indentation Brian Foster
2013-02-19 16:37 ` [PATCH v3 2/7] xfs: push rounddown_pow_of_two() to after prealloc throttle Brian Foster
2013-02-19 16:37 ` [PATCH v3 3/7] xfs: cap prealloc size to free space before shift Brian Foster
2013-02-19 21:48 ` Dave Chinner
2013-02-19 22:29 ` Brian Foster
2013-02-19 23:19 ` Dave Chinner
2013-02-20 13:17 ` Brian Foster [this message]
2013-02-19 16:37 ` [PATCH v3 4/7] xfs: pass xfs_dquot to xfs_qm_adjust_dqlimits() instead of xfs_disk_dquot_t Brian Foster
2013-02-19 16:37 ` [PATCH v3 5/7] xfs: xfs_dquot prealloc throttling watermarks and low free space Brian Foster
2013-02-19 23:08 ` Dave Chinner
2013-02-20 13:17 ` Brian Foster
2013-02-19 16:37 ` [PATCH v3 6/7] xfs: add quota-driven speculative preallocation throttling Brian Foster
2013-02-19 16:37 ` [PATCH v3 7/7] xfs: xfs_iomap_prealloc_size() tracepoint Brian Foster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5124CD01.1050602@redhat.com \
--to=bfoster@redhat.com \
--cc=david@fromorbit.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox