xfs
[Top] [All Lists]

Re: block allocations for the refcount btree

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: block allocations for the refcount btree
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Fri, 12 Feb 2016 23:48:27 -0800
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, "Darrick J. Wong" <darrick.wong@xxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20160213023310.GC14668@dastard>
References: <20160210093011.GA19147@xxxxxxxxxxxxx> <20160210095010.GC23904@xxxxxxxxxxxxxxxx> <20160210190738.GA13051@xxxxxxxxxxxxx> <20160210214058.GN14668@dastard> <20160212191046.GA28421@xxxxxxxxxxxxx> <20160213023310.GC14668@dastard>
User-agent: Mutt/1.5.24 (2015-08-30)
On Sat, Feb 13, 2016 at 01:33:10PM +1100, Dave Chinner wrote:
> > allocate an extent (or rather just a single block) in xfs_alloc_ag_vextent
> > as called from xfs_refcountbt_alloc_block.  The reservation helps us to
> > ensure this block is always available, but we still need to account for
> > that in xfs_trans_reserve(), which we currently don't do for itruncate
> > transactions.  
> 
> Ok, so we may have two different issues with a similar failure
> symptom. As it is, I don't think this is a show stopper - we're
> expecting to find these sorts of issues as we go along (hence the
> experimental tag on the feature) and I think, at this point, getting
> review and an initial merge done is more important...

This triggers 100% reproducible over NFS, and as outlined I'm
also pretty sure about the root cause.  I don't think this is something
to be ignored.

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