Re: [PATCH 1/5] xfs: bump up reserved blocks in xfs_alloc_set_aside

[Brian Foster <bfoster@redhat.com>]

On Sun, Jan 08, 2017 at 11:30:28AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 04, 2017 at 09:33:51AM -0500, Brian Foster wrote:
> > Presumably this patch addresses the potential deadlock issues from the
> > previous version, but the commit log description makes no mention of it
> > whatsoever. While the code seems fine, I think the commit log
> > description needs more information wrt to that situation and the
> > relationship/dependency with minleft.
> 
> Ok.
> 
> > The comment above xfs_alloc_set_aside() already touches on the writeback
> > situation, but why 4 blocks per ag? Wasn't the intent to use
> > worst_indlen() since that's the base for minleft?
> 
> No, I've given up on that.  worst_indlen deals with the fact that
> for converting a delayed extent of a given length we might need multiple
> real extents, possible in different AGs.
> 
> This version of the series keeps the previous minleft that is for just
> allocating a single extent in the AG - the callers will handle "short"
> returns from xfs_bmapi_write and just start a new allocation.  And
> except for a corner case in the large directory block allocation code
> these are in a new / rolled over transaction.  Fixing the latter also
> is on my todo list, but it's another big issue that so far hasn't
> trigger in practive, so I'd like to keep it in a separate series.
> 

Ok, anything you can include in the commit log and/or comment that helps
clarify that is appreciated.

Brian

> > Also, it looks like this causes a regression in xfs/004. On a quick
> > look, we might just need a test update however...
> 
> Yes.  Hard to do in a series for the kernel, though :)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html