Re: block allocations for the refcount btree

Darrick J. Wong
2016-03-02T16:41:35Z

On Wed, Mar 02, 2016 at 01:59:32AM -0800, Christoph Hellwig wrote:
> On Tue, Mar 01, 2016 at 09:24:11PM -0800, Darrick J. Wong wrote:
> > I've rebased my trees and pushed them all to github.
> >
> > The for-dave-for-4.6 kernel and progs branches are the giant piles of patches
> > against Dave's for-next integration trees which (I think) are being reviewed
> > for 4.6.
> >
> > The for-dave branches are against upstream as they've always been.
>
> BTW, what's the point of for-dave vs for-dave-for-4.6 for xfsprogs?

for-dave-for-4.6 = all the stuff I'm pushing to Dave for 4.6
for-dave = all the stuff from my dev tree minus the non-XFS stuff

("non XFS stuff" means all the ext4 fixes, etc.)

> > New patches have been added on the end of the patchset.
> >
> > I noticed that generic/139 crashes for-dave with a 1k block size due something
> > or other sending us bio->bi_bdev == NULL. This seems to be sorted out somehow
> > in for-next. Other than that I haven't seen any problems... but I've only
> > run against x64 on bare XFS. Will run other arches/NFS/etc tonight/tomorrow.
> >
> > The transaction block reservation complaints should be fixed now, and I
> > think the transaction reservations have been fixed too... or at least they
> > don't show up on the tinydisk test setup. But all that means is that someone
> > else will find it, probably within the first 3 minutes of testing. :P
>
> Passes on NFS without hitting the space reservation issue, and passes
> on XFS without new regression. The odd transaction (not space)
> reservation assert in xfs/140 that I started to myesteriously 100%
> reproduce last week still is around on XFS. I'll see if I can fix that
> or at least triage it further..

Hmm, I'll give it a spin when I get in later. Can you send me xfs_info
output so I can try to construct an equivalent reproducer setup?

--D