On Thu, Mar 03, 2016 at 06:05:56AM -0800, Christoph Hellwig wrote: > On Wed, Mar 02, 2016 at 01:21:01PM -0800, Darrick J. Wong wrote: > > Ok. I think the problem is that making changes to the refcount btree eats > > up our entire reservation in certain cases. Can you try the following bandaid? > > This should give us enough room to handle splitting the btree at both ends > > of a range that we're refcount-changing. > > This seems to work in general. I ran into one log related hang when > running -g auto on nfs, but it's not been reproducible so far. It still breaks on 1k block filesystems, which confirms my suspicions that we really need to have enough space in the reservation to handle the worst case that every block in a n-block truncation has a separate refcountbt record. :( :( (Or break up our truncation activities, I suppose...) --D _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
