Re: interest in post-mortem examination of a BTRFS system and improving the btrfs-code?

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

 





2019-04-05 09:07, Chris Murphy:
On Fri, Apr 5, 2019 at 12:45 AM Nik. <btrfs@xxxxxxxxxxxxx> wrote:

Sorry, I forgot this. Hier is the output:

# btrfs-image -c 9 -ss /dev/sdj3 /mnt/b/sdj3.img
WARNING: cannot find a hash collision for '..', generating garbage, it
won't match indexes

The new image is same size, and since it seems small to me I am
attaching it to this mail.

What do you get for `btrfs insp dump-t -d /dev/` ?

The output is long, so I have gzip-ed and attached the stdout of the command (no errors).

Once I restore it, I get


$ sudo btrfs insp dump-t -d /dev/mapper/vg-nik
btrfs-progs v4.20.2
checksum verify failed on 90195087360 found 6036BAAE wanted 7C05A75D
checksum verify failed on 90195087360 found 6036BAAE wanted 7C05A75D
bad tree block 90195087360, bytenr mismatch, want=90195087360,
have=7681037117263365436
Couldn't setup device tree
ERROR: unable to open /dev/mapper/vg-nik
$ sudo btrfs insp dump-t -r /dev/mapper/vg-nik
btrfs-progs v4.20.2
checksum verify failed on 90195087360 found 6036BAAE wanted 7C05A75D
checksum verify failed on 90195087360 found 6036BAAE wanted 7C05A75D
bad tree block 90195087360, bytenr mismatch, want=90195087360,
have=7681037117263365436
Couldn't setup device tree
ERROR: unable to open /dev/mapper/vg-nik
$

There is a valid superblock however. So it restored something, just
not everything, not sure. Might be related to create failed success!

This does not "ring a bell", I do not understand it.
Should I try something else - tell me.

Kind regards,

Nik.
--

Attachment: sdj3_dump-tree.log.gz
Description: application/gzip


[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