On Fri, Mar 18, 2011 at 3:52 AM, Chris Mason <chris.mason@xxxxxxxxxx> wrote:
> 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.
Voting with two participants (would be better to have at least three,
though theory says even this is insufficient in the presence of
failures :)) is naturally deficient, so you are right in general
except one particular case: when 2nd copy passes CRC _and_
verification, and two copies differ by a bit pattern undetectable by
CRC in use.
This is a corner case, of course, but the price to pay for false
positive (full fsck with associated downtime) is high enough to make
it worth a deeper dive.
Regards,
Andrey
>
> -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
