summaryrefslogtreecommitdiff
path: root/cmds-check.c
Commit message (Collapse)AuthorAge
* Btrfs-progs: commit the csum_root if we do --init-csum-treeJosef Bacik2013-08-09
| | | | | | | | | | | | | This is just an oddity with the commit stuff in btrfs-progs. It will just update the generation of the root you call with, which in btrfsck case would have been the fs_root. But because we didn't actually update the fs_root we wouldn't have cow'ed the fs root and therefore the generation will not match the node which will make the file system unmountable. Fix this by calling with the csum_root which is the one we're messing with. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* btrfs-progs: pass up return value of walk_down_treeLin Ming2013-08-09
| | | | | | | | | Pass up return value of walk_down_tree, so the caller can handle it. This also fixes a segfault when read_tree_block fails with NULL returned. Signed-off-by: Lin Ming <mlin@kernel.org> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: move btrfs_fsck_reinit_root to cmds-check.cEric Sandeen2013-08-09
| | | | | | | | | | | cmds-check.c contains the only caller of btrfs_fsck_reinit_root; moving it to the caller's source file gets ctree.c a little closer to kernelspace, although it does require exporting add_root_to_dirty_list(), which is not done in kernelspace. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* btrfsck: fix incorrect casting on items in the corrupt_blocks treeChris Mason2013-07-05
| | | | | | | check_extent_refs is pinning down all the corrupt tree blocks it finds, but it is incorrectly casting these to an extent_record first. Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: Add chunk rebuild function for RAID1/SINGLE/DUPMiao Xie2013-07-03
| | | | | | | | | | | | | Add chunk rebuild for RAID1/SINGLE/DUP to chunk-recover command. Before this patch chunk-recover can only scan and reuse the old chunk data to recover. With this patch, chunk-recover can use the reference between chunk/block group/dev extent to rebuild the whole chunk tree even when old chunks are not available. Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: Add chunk recover function - using old chunk itemsMiao Xie2013-07-03
| | | | | | | | | | | | | | | | | | Add chunk-recover program to check or rebuild chunk tree when the system chunk array or chunk tree is broken. Due to the importance of the system chunk array and chunk tree, if one of them is broken, the whole btrfs will be broken even other data are OK. But we have some hint(fsid, checksum...) to salvage the old metadata. So this function will first scan the whole file system and collect the needed data(chunk/block group/dev extent), and check for the references between them. If the references are OK, the chunk tree can be rebuilt and luckily the file system will be mountable. Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: Add block group check funtionMiao Xie2013-07-03
| | | | | | | | | This patch adds the function to check correspondence between block group, chunk and device extent. Original-signed-off-by: Cheng Yang <chenyang.fnst@cn.fujitsu.com> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: extend the extent cache for the device extentMiao Xie2013-07-03
| | | | | | | | | | | | As we know, btrfs can manage several devices in the same fs, so [offset, size] is not sufficient for unique identification of an device extent, we need the device id to identify the device extents which have the same offset and size, but are not in the same device. So, we added a member variant named objectid into the extent cache, and introduced some functions to make the extent cache be suitable to manage the device extent. Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: introduce common insert/search/delete functions for rb-treeMiao Xie2013-07-03
| | | | | | | | | In fact, the code of many rb-tree insert/search/delete functions is similar, so we can abstract them, and implement common functions for rb-tree, and then simplify them. Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: fix reference check for roots in btrfsckJosef Bacik2013-06-19
| | | | | | | | | | | | | I noticed that I was getting these errors on a bigger file system with more snapshots that had been removed. This check is bogus since we won't inc rec->found_ref if we don't find a REF_KEY _and_ a DIR_ITEM, so we only have to worry about there being no references to a root if it actually has a root item. If it doesn't then it's just referenced by things that will go no where anyway. With this patch fsck no longer incorrectly complains about this file system image I have. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: fix incorrect root backref errors in fsckJosef Bacik2013-06-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | A user reported that fsck was complaining about unresolved refs for some snapshots. You can reproduce this by doing mkfs.btrfs /dev/sdb mount /dev/sdb /mnt btrfs subvol snap /mnt/ /mnt/a btrfs subvol snap /mnt/ /mnt/b btrfs subvol del /mnt/a umount /mnt btrfsck /dev/sdb and you'd get this unresolved ref root 258 dir 256 index 2 namelen 1 name a error 600 because snapshot b has a dir item that points to a. Except we encode in our root ref the dirid of the ref holder, and if it doesn't match we just give it back a empty directory since we can't hardlink directories. This makes the check in btrfsck bogus, when we delete a we remove the ref key for it so any lookups into /mnt/b/a will just give a blank directory as it's supposed to. Fix this by only saying the backref is reachable if there is both a DIR_ITEM and a REF_KEY for the given root. With this patch I no longer see errors when running this reproducer. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: fix fsck dealing with finding backrefs firstJosef Bacik2013-06-19
| | | | | | | | | | | | | | | There is a problem where if we find a backref extent record first that doesn't match a extent item we will delete some of the duplicates but not others. In order to deal with this we need to make sure we only pay attention to duplicates that actually have duplicate extent items. If a extent_rec has a duplicate but the record itself doesn't have an associated extent item we promote the duplicate to the extent record and just discard the original extent_rec since it was just added by the backref. We copy the backref onto the promoted extent record and then continue processing. This allowed me to fix a file system that previously was not able to be fixed by fsck. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: fix free space cache checksJosef Bacik2013-06-19
| | | | | | | | | | | | This fixes two bugs with the free space cache checker. First is we apparently always use root->sectorsize for our unit in the kernel so we have to do that in progs otherwise bitmaps turn out to not look right if we have leafsize != sectorsize. The second is a small issue if we had skinny metadata extents set, we wouldn't advance last properly because we unconditionally use key.offset instead of root->leafsize. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: add --init-extent-tree to btrfsckJosef Bacik2013-06-19
| | | | | | | | | | | | | In some cases the extent tree can just be so gone there is no point in trying to figure out how to put it back together. So add a --init-extent-tree mode which will zero out the extent tree and then re-add extents for all of the blocks we find. This will also undo any balance that was going on at the time of the crash, this is needed because the reloc tree seems to confuse fsck at the moment. With this patch I can put back together a users file system that was completely gone. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: make fsck fix certain file extent inconsistenciesJosef Bacik2013-06-19
| | | | | | | | | | | | | | | | | | | | | | The tree log bug I introduced could create inconsistent file extent entries in the file system tree and in some worst cases even create multiple extent entries for the same entry. To fix this we need to do a few things 1) Keep track of extent items that overlap and then pick the one that covers the largest area and delete the rest of the items. 2) Keep track of file extent items that land in extent items but don't match disk_bytenr/disk_num_bytes exactly. Once we find these we need to figure out who is the right ref and then fix all of the other refs to agree. Each of these cases require a complete rescan of all of the extents, so unfortunately if you hit this particular problem the fsck is going to take quite a while since it will likely rescan all the trees 2 or 3 times. With this patch the broken file system a user sent me is fixed and a broken file system that was created by my reproducer is also fixed. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: add the ability to find mismmatching backrefsJosef Bacik2013-05-10
| | | | | | | | | | | | | An unfortunate side effect to my fsync bug means that anybody who didn't hit the BUG_ON() during tree log replay would have ended up with a corrupted file system. Currently our fsck does not catch this because it just looks for bytenrs for backrefs, it doesn't look at the num_bytes at all. So this patch makes us keep track of how big the backrefs are, since their disk_num_bytes _have_ to match the number of bytes for the actual extent item. With this patch fsck now finds problems with a file system it previously thought was ok. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com>
* 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 <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: make restore deal with really broken file systemsJosef Bacik2013-04-23
| | | | | | | | | | | | | | | | | All we need for restore to work is the chunk root, the tree root and the fs root we want to restore from. So to do this we need to make a few adjustments 1) Make open_ctree_fs_info fail completely if it can't read the chunk tree. There is no sense in continuing if we can't read the chunk tree since we won't be able to translate logical to physical blocks. 2) Use open_ctree_fs_info in restore, and if we didn't load a tree root or fs root go ahead and try to set those up manually ourselves. This is related to work I did last year on restore, but it uses the open_ctree_fs_info instead of my open coded open_ctree. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com>
* Btrfs-progs: fix csum check when extent lands on block groupJosef Bacik2013-04-23
| | | | | | | | | | | | | | | | I was running fsync() tests and noticed that occasionally I was getting a bunch of errors from fsck complaining about csums not having corresponding extents. Thankfully after a few days of debugging this it turned out to be a bug with fsck. The csums were for an extent that started at the same offset as a block group, and were offset within the extent. So the search put us out at the block group item and we just walked forward from there, never finding the actual extent. This is because the block group item key is higher than the extent item key, so it comes first. In order to fix this we need to check and see if we landed on a block group item and take another step backwards to make sure we end up at the extent item. With this patch my reproducer no longer finds csums that don't have matching extent records. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com>
* Btrfs-progs: add csum tree checks to btrfsckJosef Bacik2013-04-23
| | | | | | | | | | Looking at a recent user problem I noticed there are weird cases we could possibly be leaving csums in place for an extent we've free'd. I don't think this can happen unless the extent tree is also corrupt, but just in case I'm adding sanity checks to btrfsck. This way we will catch this if it happens normally since xfstests runs btrfsck between each run. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com>
* Btrfs-progs: fix segfault in fsck if the chunk tree is bogusJosef Bacik2013-04-23
| | | | | | | | | I made open_ctree fail if the chunk tree couldn't be open, which means that fsck now segfaults if it can't open the chunk tree. So fix fsck to check the fs_info we get back from open_ctree_fsinfo to make sure it's valid and exit if it's not instead of segfaulting. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com>
* 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 <jbacik@fusionio.com>
* Btrfs-progs: add skinny metadata support to progs V3Josef Bacik2013-04-23
| | | | | | | | | This fixes up the progs to properly deal with skinny metadata. This adds the -x option to mkfs and btrfstune for enabling the skinny metadata option. This also makes changes to fsck so it can properly deal with the skinny metadata entries. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com>
* btrfs-progs: separate super_copy out of fs_infoDavid Sterba2013-03-10
| | | | | | | | | Allocate fs_info::super_copy dynamically of full BTRFS_SUPER_INFO_SIZE and use it directly for saving superblock to disk. This fixes incorrect superblock checksum after mkfs. Signed-off-by: David Sterba <dsterba@suse.cz>
* Btrfs-progs: fix segmentation fault of "btrfs check"Tsutomu Itoh2013-02-27
| | | | | | | | | | | | Segmentation fault occurred in the following command. # btrfs check /dev/sdc7 No valid Btrfs found on /dev/sdc7 Segmentation fault (core dumped) Fix it. Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
* Btrfs-progs: add btrfsck functionality to btrfsIan Kumlien2013-02-12
| | | | | | | | This patch includes the functionality of btrfs, it's found as "btrfs check". Signed-off-by: Ian Kumlien <pomac@demius.net> Signed-off-by: David Sterba <dsterba@suse.cz>
* Btrfs-progs: Rename btrfsck.c -> cmds-check.cIan Kumlien2013-02-12
In preparation for merging btrfsck functionality in to btrfs. Signed-off-by: Ian Kumlien <pomac@demius.net>