Btrfs: rework allocation clustering
authorChris Mason <chris.mason@oracle.com>
Fri, 3 Apr 2009 13:47:43 +0000 (09:47 -0400)
committerChris Mason <chris.mason@oracle.com>
Fri, 3 Apr 2009 13:47:43 +0000 (09:47 -0400)
commitfa9c0d795f7b57c76560b7fac703f5d341210e28
tree74d9d9846e21ce5b99738f3cc13b855fb63d1eba
parent8e73f275011b3264a87339fd9f1690e944e381c9
Btrfs: rework allocation clustering

Because btrfs is copy-on-write, we end up picking new locations for
blocks very often.  This makes it fairly difficult to maintain perfect
read patterns over time, but we can at least do some optimizations
for writes.

This is done today by remembering the last place we allocated and
trying to find a free space hole big enough to hold more than just one
allocation.  The end result is that we tend to write sequentially to
the drive.

This happens all the time for metadata and it happens for data
when mounted -o ssd.  But, the way we record it is fairly racey
and it tends to fragment the free space over time because we are trying
to allocate fairly large areas at once.

This commit gets rid of the races by adding a free space cluster object
with dedicated locking to make sure that only one process at a time
is out replacing the cluster.

The free space fragmentation is somewhat solved by allowing a cluster
to be comprised of smaller free space extents.  This part definitely
adds some CPU time to the cluster allocations, but it allows the allocator
to consume the small holes left behind by cow.

Signed-off-by: Chris Mason <chris.mason@oracle.com>
fs/btrfs/ctree.h
fs/btrfs/disk-io.c
fs/btrfs/extent-tree.c
fs/btrfs/free-space-cache.c
fs/btrfs/free-space-cache.h [new file with mode: 0644]
fs/btrfs/transaction.c