| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
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>
|
|
|
In preparation for merging btrfsck functionality in to btrfs.
Signed-off-by: Ian Kumlien <pomac@demius.net>
|
