Re: BTRFS Metadata Corruption Prevents Scrub and btrfs check

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Read error at byte 0, while reading 3975 bytes: Input/output error

Bad news. That means that probably the disk is damaged and
further issues may happen.

>         corrected errors: 0, uncorrectable errors: 2, unverified errors: 0

Even worse news.

> Incorrect local backref count on 5165855678464 root 259 owner 1732872
> offset 0 found 0 wanted 1 back 0x3ba80f40
> Backref disk bytenr does not match extent record,
> bytenr=5165855678464, ref bytenr=7880454922968236032
> backpointer mismatch on [5165855678464 28672]

"Better" news. In practice a single metadata leaf node is
corrupted in back references. You might be lucky and that might
be rebuildable, but I don't know enough about the somewhat
intricate Btrfs metadata trees to figure that out. Some metadata
is rebuildable from other metadata with a tree scan, some not.

In general metadata in Btrfs is fairly intricate and metadata
block loss is pretty fatal, that's why metadata should most
times be redundant as in 'dup' or 'raid1' or similar:

http://www.sabi.co.uk/blog/16-two.html?160817#160817
--
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




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux