From 6bdcf26ade8825ffcdc692338e715cd7ed0820d8 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Fri, 3 Nov 2017 10:34:46 -0700 Subject: xfs: use a b+tree for the in-core extent list Replace the current linear list and the indirection array for the in-core extent list with a b+tree to avoid the need for larger memory allocations for the indirection array when lots of extents are present. The current extent list implementations leads to heavy pressure on the memory allocator when modifying files with a high extent count, and can lead to high latencies because of that. The replacement is a b+tree with a few quirks. The leaf nodes directly store the extent record in two u64 values. The encoding is a little bit different from the existing in-core extent records so that the start offset and length which are required for lookups can be retreived with simple mask operations. The inner nodes store a 64-bit key containing the start offset in the first half of the node, and the pointers to the next lower level in the second half. In either case we walk the node from the beginninig to the end and do a linear search, as that is more efficient for the low number of cache lines touched during a search (2 for the inner nodes, 4 for the leaf nodes) than a binary search. We store termination markers (zero length for the leaf nodes, an otherwise impossible high bit for the inner nodes) to terminate the key list / records instead of storing a count to use the available cache lines as efficiently as possible. One quirk of the algorithm is that while we normally split a node half and half like usual btree implementations we just spill over entries added at the very end of the list to a new node on its own. This means we get a 100% fill grade for the common cases of bulk insertion when reading an inode into memory, and when only sequentially appending to a file. The downside is a slightly higher chance of splits on the first random insertions. Both insert and removal manually recurse into the lower levels, but the bulk deletion of the whole tree is still implemented as a recursive function call, although one limited by the overall depth and with very little stack usage in every iteration. For the first few extents we dynamically grow the list from a single extent to the next powers of two until we have a first full leaf block and that building the actual tree. The code started out based on the generic lib/btree.c code from Joern Engel based on earlier work from Peter Zijlstra, but has since been rewritten beyond recognition. Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong --- fs/xfs/scrub/bmap.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) (limited to 'fs/xfs/scrub/bmap.c') diff --git a/fs/xfs/scrub/bmap.c b/fs/xfs/scrub/bmap.c index be0bc11b6594..39fb2a537aea 100644 --- a/fs/xfs/scrub/bmap.c +++ b/fs/xfs/scrub/bmap.c @@ -168,7 +168,6 @@ xfs_scrub_bmapbt_rec( struct xfs_scrub_btree *bs, union xfs_btree_rec *rec) { - struct xfs_bmbt_rec_host ihost; struct xfs_bmbt_irec irec; struct xfs_scrub_bmap_info *info = bs->private; struct xfs_inode *ip = bs->cur->bc_private.b.ip; @@ -193,9 +192,7 @@ xfs_scrub_bmapbt_rec( } /* Set up the in-core record and scrub it. */ - ihost.l0 = be64_to_cpu(rec->bmbt.l0); - ihost.l1 = be64_to_cpu(rec->bmbt.l1); - xfs_bmbt_get_all(&ihost, &irec); + xfs_bmbt_disk_get_all(&rec->bmbt, &irec); return xfs_scrub_bmap_extent(ip, bs->cur, info, &irec); } -- cgit v1.2.3-58-ga151