aboutsummaryrefslogtreecommitdiffstats
path: root/disk-io.c
diff options
context:
space:
mode:
authorJosef Bacik <jbacik@fusionio.com>2013-04-16 13:00:56 -0400
committerDavid Sterba <dsterba@suse.cz>2013-04-23 18:56:27 +0200
commit18ce0501ce8a6bc2d66b6bf11358d284919c5d3c (patch)
tree92e6b1101e44123b2e690e7f3be2e916568409d2 /disk-io.c
parent617769147f96bcd05aa9a5c8534b29d00fdd8b90 (diff)
downloadbtrfs-progs-18ce0501ce8a6bc2d66b6bf11358d284919c5d3c.tar.gz
btrfs-progs-18ce0501ce8a6bc2d66b6bf11358d284919c5d3c.tar.xz
btrfs-progs-18ce0501ce8a6bc2d66b6bf11358d284919c5d3c.zip
Btrfs-progs: fix csum check when extent lands on block group
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>
Diffstat (limited to 'disk-io.c')
0 files changed, 0 insertions, 0 deletions