xfs
[Top] [All Lists]

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

To: Mark Goodwin <markgw@xxxxxxx>, lachlan@xxxxxxx, xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
Subject: Re: [PATCH] Increase the default size of the reserved blocks pool
From: Lachlan McIlroy <lachlan@xxxxxxx>
Date: Tue, 30 Sep 2008 16:08:15 +1000
In-reply-to: <20080930042526.GB23915@disturbed>
References: <48E097B5.3010906@xxxxxxx> <48E19C59.7090303@xxxxxxx> <20080930042526.GB23915@disturbed>
Reply-to: lachlan@xxxxxxx
User-agent: Thunderbird 2.0.0.17 (X11/20080914)
Dave Chinner wrote:
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....


We tossed around the idea of preventing applications from reducing the
size of the reserved pool so that they could not weaken the integrity
of the filesystem by removing critical resources.  We need to support
reducing the pool size because we do so on unmount.

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