[Top] [All Lists]

Re: [PATCH] Increase the default size of the reserved blocks pool

To: Mark Goodwin <markgw@xxxxxxx>
Subject: Re: [PATCH] Increase the default size of the reserved blocks pool
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 30 Sep 2008 14:25:26 +1000
Cc: lachlan@xxxxxxx, xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <48E19C59.7090303@sgi.com>
Mail-followup-to: Mark Goodwin <markgw@xxxxxxx>, lachlan@xxxxxxx, xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
References: <48E097B5.3010906@sgi.com> <48E19C59.7090303@sgi.com>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
On Tue, Sep 30, 2008 at 01:26:17PM +1000, Mark Goodwin wrote:
> Lachlan McIlroy wrote:
>> The current default size of the reserved blocks pool is easy to deplete
>> with certain workloads, in particular workloads that do lots of concurrent
>> delayed allocation extent conversions.  If enough transactions are running
>> in parallel and the entire pool is consumed then subsequent calls to
>> xfs_trans_reserve() will fail with ENOSPC.  Also add a rate limited
>> warning so we know if this starts happening again.
> Should we also change the semantics of the XFS_SET_RESBLKS ioctl
> so that the passed in value is the minimum required by the caller,
> i.e. silently succeed if the current value is more than that?

No. If we are asked to reduce the size of the pool, then we should
do so. The caller might have reason for wanting the pool size
reduced. e.g. using it to trigger early ENOSPC notification so that
there is always room to write critical application data when the
filesystem fills up....


Dave Chinner

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