[PATCH 4/5] repair: don't cache large blkmap allocations

Alex Elder aelder at sgi.com
Thu Oct 13 04:57:57 CDT 2011


On Mon, 2011-10-10 at 12:08 +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner at redhat.com>
> 
> We currently use thread local storage for storing blkmap allocations
> from one inode to another as a way of reducing the number of short
> term allocations we do. However, the stored allocations can only
> ever grow, so once we've done a large allocation we never free than
> memory even if we never need that much memory again. This can occur
> if we have corrupted extent counts in inodes, and can greatly
> increase the memory footprint of the repair process.
> 
> Hence if the cached blkmap array id greater than a reasonable number
> of extents (say 100,000), then don't store the blkmap in TLS and
> instead free it.
> 
> Signed-off-by: Dave Chinner <dchinner at redhat.com>

Looks good.

Reviewed-by: Alex Elder <aelder at sgi.com>





More information about the xfs mailing list