path: root/free-space-cache.c
Commit message (Collapse)AuthorAge
* btrfs-progs: check the free space tree in btrfsckOmar Sandoval2016-01-12
| | | | | | | | | | This reuses the existing code for checking the free space cache, we just need to load the free space tree. While we do that, we check a couple of invariants on the free space tree itself. This requires pulling in some code from the kernel to exclude the super stripes. Signed-off-by: Omar Sandoval <> Signed-off-by: David Sterba <>
* btrfs-progs: add newline to some error messagesTsutomu Itoh2015-08-31
| | | | | | | | | Added a missing newline to some error messages. Also printf() was changed to fprintf(stderr) for error messages. Signed-off-by: Tsutomu Itoh <> Reviewed-by: Zhao Lei <> Signed-off-by: David Sterba <>
* btrfs-progs: check for matching free space in cacheJosef Bacik2015-04-24
| | | | | | | | | | | We have this check in the kernel but not in userspace, which makes fsck fail when we wouldn't have a problem in the kernel. This was meant to catch this case because it really isn't good, unfortunately it will require a design change to fix in the kernel so in the meantime add this check so we can be sure our tests only catch real problems. Thanks, Signed-off-by: Josef Bacik <> Signed-off-by: David Sterba <>
* btrfs-progs: Remove a unused function offset_to_bitmap()Qu Wenruo2014-12-19
| | | | | | | | | | | | | | Fix the following clang warning: free-space-cache.c:464:19: warning: unused function 'offset_to_bitmap' [-Wunused-function] static inline u64 offset_to_bitmap(struct btrfs_free_space_ctl *ctl, ^ 1 warning generated. Signed-off-by: Qu Wenruo <> Reviewed-by: Satoru Takeuchi <> Signed-off-by: David Sterba <>
* btrfs-progs: make free space checker work on non-4k sectorsize filesystemsDavid Sterba2014-10-10
| | | | | | | | | The value of sector for space cache was hardcoded to 4k, and used to calculate bitmap sizes. In kernel, the BITS_PER_BITMAP is derived from PAGE_CACHE_SIZE which is not available for userspace, that can also deal with filesystem of varying sectorsize. Signed-off-by: David Sterba <>
* btrfs-progs: clean fsck noise for free inode generation 0Gui Hecheng2014-08-22
| | | | | | | | | | | | | | | | When we write a btrfs to full and then we have no space left for free space cache. The btrfs check will output msg as follows which is noise indeed: # free space inode generation (0) did not match free space cache generation (XXX) When the free space cache is not written out normally, the free inode generation will be 0. In this condition, no noise should be outputed. Also, check 0-sized inode eariler together with 0-generationed inode. Signed-off-by: Gui Hecheng <> Signed-off-by: David Sterba <>
* btrfs-progs: cleanup nonsense ret value assignmentGui Hecheng2014-03-21
| | | | | | | | | The "ret" will be soon used to hold the return value of another function, assign -1 to it before is nonsense. Signed-off-by: Gui Hecheng <> Signed-off-by: David Sterba <> Signed-off-by: Chris Mason <>
* Btrfs-progs: check return value of read_tree_block() in ↵Eryu Guan2014-01-31
| | | | | | | | | | | | | | | | | | | check_chunks_and_extents() The following steps could trigger btrfs segfault: mkfs -t btrfs -m raid5 -d raid5 /dev/loop{0..3} losetup -d /dev/loop2 btrfs check /dev/loop0 The reason is that read_tree_block() returns NULL and add_root_to_pending() dereferences it without checking it first. Also replace a BUG_ON with proper error checking. Signed-off-by: Eryu Guan <> Signed-off-by: David Sterba <> Signed-off-by: Chris Mason <>
* btrfs-progs: remove NULL-ptr judge before free for btrfs-progsGui Hecheng2014-01-31
| | | | | | | | | free(3) already checks the pointer for NULL, no need to do it on your own. This patch make the change globally. Signed-off-by: Gui Hecheng <> Signed-off-by: David Sterba <> Signed-off-by: Chris Mason <>
* btrfs-progs: make many private symbols staticZach Brown2013-09-03
| | | | | | Signed-off-by: Zach Brown <> Signed-off-by: David Sterba <> Signed-off-by: Chris Mason <>
* btrfs-progs: mark static & remove unused from shared kernel codeEric Sandeen2013-09-03
| | | | | | | | | | | In files copied from the kernel, mark many functions as static, and remove any resulting dead code. Some functions are left unmarked if they aren't static in the kernel tree. Signed-off-by: Eric Sandeen <> Signed-off-by: Chris Mason <>
* btrfs-progs: drop unused parameter from btrfs_release_pathEric Sandeen2013-09-03
| | | | | | | | | | | | | | | Port of commit b3b4aa7 to userspace. parameter tree root it's not used since commit 5f39d397dfbe140a14edecd4e73c34ce23c4f9ee ("Btrfs: Create extent_buffer interface for large blocksizes") This gets userspace a tad closer to kernelspace by removing this unused parameter that was all over the codebase... Signed-off-by: Eric Sandeen <> Signed-off-by: David Sterba <> Signed-off-by: Chris Mason <>
* Btrfs-progs: add a newline to a free space cache messageJosef Bacik2013-06-19
| | | | | | | Left out a newline in the generation check printf. Signed-off-by: Josef Bacik <> Signed-off-by: Chris Mason <>
* Btrfs-progs: init free space ctl with proper unitJosef Bacik2013-05-06
| | | | | | | | | | | btrfsck was blowing up when checking the free space cache when we ran xfstests with -l 64k. That is because I was init'ing the free space ctl to whatever the leafsize was, which isn't right for data block groups. With this patch btrfsck no longer complains. This also fixes a tiny little typo in free-space-cache.c I noticed while figuring this problem out. Thanks, Signed-off-by: Josef Bacik <> Signed-off-by: Chris Mason <>
* Btrfs-progs: add a free space cache checker to fsck V2Josef Bacik2013-04-23
In trying to track down a weird tree log problem I wanted to make sure that the free space cache was actually valid, which we currently have no way of doing. So this patch adds a bunch of support for the free space cache code and then a checker to fsck. Basically we go through and if we can actually load the free space cache then we will walk the extent tree and verify that the free space cache exactly matches what is in the extent tree. Hopefully this will always be correct, the only time it wouldn't is if the extent tree is corrupt or we have some sort of awful bug in the free space cache. Thanks, Signed-off-by: Josef Bacik <>