On Fri, 2011-01-21 at 04:22 -0500, Christoph Hellwig wrote: > plain text document attachment (xfs-remove-duplicate-extent-handling) > With the recent changes we never re-used busy extents. Remove all handling > of them and replace them with asserts. This also effectively reverts > commit 955833cf2ad0aa39b336e853cad212d867199984 > > "xfs: make the log ticket ID available outside the log infrastructure" I have a hunch that this, for you, was an itch that needed scratching. Anyway, I was wondering about the following when xfs_alloc_busy_search_trim() was added. Maybe you could just offer a quick explanation. If we always skip busy extents when allocating blocks, will we still satisfy allocation requests when we're almost out of space? Will a log flush cause busy extents to become non-busy when we find nothing available, thereby always satifying requests we would have satisfied (perhaps with busy extents) previously? Second, is there *anything* that could be said about the resulting allocation patterns? Will they be affected in any adverse (or beneficial) way by skipping busy extents? (Will we get more fragmented earlier, for a contrived example?) I have no feeling for it but thought the question ought to be asked... Outside of the above, I think this patch looks fine. The xfs_alloc_busy_search() call becomes a debug-only function (and might as well be surrounded by DEBUG ifdef's, accordingly), ensuring an allocated extent is never found in the busy list. I'm not signing off on this for now, though, because I want to hear back on the comments from the previous patch, and I think you're going to be re-posting the series anyway. -Alex > Signed-off-by: Christoph Hellwig <hch@xxxxxx> > > Index: xfs/fs/xfs/xfs_ag.h > ========================================== _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
