On 01/22/2013 05:37 PM, Dave Chinner wrote: > 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. ;) > Ok, thanks for the explanation. In fact, it actually sounds like I'll need to include (or preserve) this case in the quota throttling set (e.g., carry the minimum free space available through the per-quota calculations along with the shift and prealloc size and apply the additional reduction based on that). Brian > Cheers, > > Dave. > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
