summaryrefslogtreecommitdiff
path: root/fs/btrfs/free-space-tree.c
AgeCommit message (Collapse)AuthorFilesLines
2016-01-29Revert "btrfs: synchronize incompat feature bits with sysfs files"Chris Mason1-7/+0
This reverts commit 14e46e04958df740c6c6a94849f176159a333f13. This ends up doing sysfs operations from deep in balance (where we should be GFP_NOFS) and under heavy balance load, we're making races against sysfs internals. Revert it for now while we figure things out. Signed-off-by: Chris Mason <clm@fb.com>
2016-01-27btrfs: don't use GFP_HIGHMEM for free-space-tree bitmap kzallocChris Mason1-1/+1
This was copied incorrectly from the __vmalloc call. Signed-off-by: Chris Mason <clm@fb.com>
2016-01-27Merge branch 'dev/fst-followup' of ↵Chris Mason1-2/+16
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into for-linus-4.5
2016-01-22btrfs: tweak free space tree bitmap allocationDavid Sterba1-2/+16
The requested bitmap size varies, observed numbers were < 4K up to 16K. Using vmalloc unconditionally would be too heavy, we'll try contiguous allocations first and fall back to vmalloc if there's no contig memory. Signed-off-by: David Sterba <dsterba@suse.com>
2016-01-21btrfs: synchronize incompat feature bits with sysfs filesDavid Sterba1-0/+7
The files under /sys/fs/UUID/features get out of sync with the actual incompat bits set for the filesystem if they change after mount (eg. the LZO compression). Synchronize the feature bits with the sysfs files representing them right after we set/clear them. Signed-off-by: David Sterba <dsterba@suse.com>
2015-12-30btrfs: don't run delayed references while we are creating the free space treeChris Mason1-4/+11
This is a short term solution to make sure btrfs_run_delayed_refs() doesn't change the extent tree while we are scanning it to create the free space tree. Longer term we need to synchronize scanning the block groups one by one, similar to what happens during a balance. Signed-off-by: Chris Mason <clm@fb.com>
2015-12-17Btrfs: implement the free space B-treeOmar Sandoval1-0/+1584
The free space cache has turned out to be a scalability bottleneck on large, busy filesystems. When the cache for a lot of block groups needs to be written out, we can get extremely long commit times; if this happens in the critical section, things are especially bad because we block new transactions from happening. The main problem with the free space cache is that it has to be written out in its entirety and is managed in an ad hoc fashion. Using a B-tree to store free space fixes this: updates can be done as needed and we get all of the benefits of using a B-tree: checksumming, RAID handling, well-understood behavior. With the free space tree, we get commit times that are about the same as the no cache case with load times slower than the free space cache case but still much faster than the no cache case. Free space is represented with extents until it becomes more space-efficient to use bitmaps, giving us similar space overhead to the free space cache. The operations on the free space tree are: adding and removing free space, handling the creation and deletion of block groups, and loading the free space for a block group. We can also create the free space tree by walking the extent tree and clear the free space tree. Signed-off-by: Omar Sandoval <osandov@fb.com> Signed-off-by: Chris Mason <clm@fb.com>