[Top] [All Lists]

Re: [PATCH 3/4] xfs: limit speculative prealloc near ENOSPC thresholds

To: Brian Foster <bfoster@xxxxxxxxxx>
Subject: Re: [PATCH 3/4] xfs: limit speculative prealloc near ENOSPC thresholds
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 23 Jan 2013 09:37:46 +1100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <50FEA326.5000402@xxxxxxxxxx>
References: <1358772835-21436-1-git-send-email-david@xxxxxxxxxxxxx> <1358772835-21436-4-git-send-email-david@xxxxxxxxxxxxx> <50FEA326.5000402@xxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Jan 22, 2013 at 09:33:10AM -0500, Brian Foster wrote:
> On 01/21/2013 07:53 AM, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@xxxxxxxxxx>
> > 
> > There is a window on small filesytsems where specualtive
> > preallocation can be larger than that ENOSPC throttling thresholds,
> > resulting in specualtive preallocation trying to reserve more space
> > than there is space available. This causes immediate ENOSPC to be
> > triggered, prealloc to be turned off and flushing to occur. One the
> > next write (i.e. next 4k page), we do exactly the same thing, and so
> > effective drive into synchronous 4k writes by triggering ENOSPC
> > flushing on every page while in the window between the prealloc size
> > and the ENOSPC prealloc throttle threshold.
> > 
> > Fix this by checking to see if the prealloc size would consume all
> > free space, and throttle it appropriately to avoid premature
> > ENOSPC...
> > 
> Would this alternatively be resolved by the updated throttling code that
> is part of my quota prealloc throttling set? I'm referring to the
> following patch in particular:
> http://oss.sgi.com/archives/xfs/2013-01/msg00003.html

Not quite. If shift is set (i.e. within either the quota or ENOSPC
throttling zone) then it will have a similar-but-not-as-drastic
effect, but the bug reported (and being fixed) is for when freespace
is outside the throttling zone, but the prealloc is large enough to
use all remaining free space. The config that this was found on was
a 100GB filesystem, so the ENOSPC throttling only kicks in at 5GB
freespace remaining, but prealloc was triggering ENOSPC flushing at
7GB freespace remaining by trying to prealloc a 8GB delalloc extent
and throttling wasn't preventing that.

In that case, your patch allows preallocation to try to use all of
the remaining free space in one go. It is likely to fail in the same
way as if it didn't cap the alloc_size to freesp, as the metadata
overhead of the delalloc reservation will push the requested amount
of space over the amount of remaining free space.

Further, even if we have throttled a prealloc of MAXEXTLEN to the
highest threshold (i.e 2^21>>6 = 2^15 = 128MB at 4k block size) we
may still be over the amount of free space remaining, and in that
case we need to keep throttling the preallocation down to below the
free space so we don't use all the remaining space in one go.

So it's really handling corner cases for a different corner to the
ones that the your code is handling. It's like a mandlebrot set -
corners within corners. ;)


Dave Chinner

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