Excerpts from Andrey Kuzmin's message of 2011-03-17 15:12:32 -0400:
> On Thu, Mar 17, 2011 at 9:18 PM, Josef Bacik <josef@xxxxxxxxxx> wrote:
> > Currently if we have corrupted items things will blow up in spectacular ways.
> > So as we read in blocks and they are leaves, check the entire leaf to make sure
> > all of the items are correct and point to valid parts in the leaf for the item
> > data the are responsible for. ÂIf the item is corrupt we will kick back EIO and
> > not read any of the copies since they are likely to not be correct either. ÂThis
> > will catch generic corruptions, it will be up to the individual callers of
> > btrfs_search_slot to make sure their items are right. ÂThanks,
> >
> > diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> > index 495b1ac..9f31e11 100644
> > --- a/fs/btrfs/disk-io.c
> > +++ b/fs/btrfs/disk-io.c
> > @@ -323,6 +323,7 @@ static int btree_read_extent_buffer_pages(struct btrfs_root *root,
> > Â Â Â Âint num_copies = 0;
> > Â Â Â Âint mirror_num = 0;
> >
> > + Â Â Â clear_bit(EXTENT_BUFFER_CORRUPT, &eb->bflags);
> > Â Â Â Âio_tree = &BTRFS_I(root->fs_info->btree_inode)->io_tree;
> > Â Â Â Âwhile (1) {
> > Â Â Â Â Â Â Â Âret = read_extent_buffer_pages(io_tree, eb, start, 1,
> > @@ -331,6 +332,14 @@ static int btree_read_extent_buffer_pages(struct btrfs_root *root,
> > Â Â Â Â Â Â Â Â Â Â!verify_parent_transid(io_tree, eb, parent_transid))
> > Â Â Â Â Â Â Â Â Â Â Â Âreturn ret;
> >
> > + Â Â Â Â Â Â Â /*
> > + Â Â Â Â Â Â Â Â* This buffer's crc is fine, but its contents are corrupted, so
> > + Â Â Â Â Â Â Â Â* there is no reason to read the other copies, they won't be
> > + Â Â Â Â Â Â Â Â* any less wrong.
> > + Â Â Â Â Â Â Â Â*/
>
> This sounds like an overstatement to me. You may be dealing with an
> error pattern CRC faled to catch, so giving up reading a mirror at
> this point seems premature.
But we have no way to tell which one is more correct, at least not
without a full fsck.
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
