On Tue, Mar 01, 2016 at 10:18:09AM -0800, Darrick J. Wong wrote: > One side effect of the per-ag block reservation code is that it reserves all > the blocks that the refcountbt will ever need at mount time, which includes > decreasing the incore fdblocks counter at mount and putting it back at unmount > time. This /should/ eliminate the need for reserving blocks in truncate > transactions, though clearly this isn't being done correctly. We're still accouting these blocks in t_blk_res_used through xfs_alloc_vextent -> xfs_alloc_ag_vextent -> xfs_trans_mod_sb. I don't really see how the reservation code changes anything about that accounting. It just ensures the allocation will succeed through xfs_ag_resv_needed in xfs_alloc_ag_vextent, and then removes the allocated block from the reservation using xfs_ag_resv_alloc_block. Maybe we need to find a way to not account for these blocks. > So what I'm saying is that I think this problem was with the AGresv code not > doing accounting correctly, and that I've fixed it in a subsequent rewrite of > the AGresv code. I'll post it later, after I figure out why generic/333 > regresses with the new code. Ok, let's see if the new version helps with the above issue. > However, there's one thing to be aware of -- if the AGresv uses up all the > blocks that were preallocated at mount time, the allocator will grab any free > blocks available and charge the blocks to the transaction, just like before. > If this ever happens (in theory we reserve enough blocks so that we can have a > refcount record for every block in the AG) then we'll still have this problem. It seems like we should simply avoid that this case ever happens. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
