[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