linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* corrupt leaf, slot offset bad
@ 2016-10-10 18:57 aron
  2016-10-10 21:03 ` Liu Bo
  0 siblings, 1 reply; 6+ messages in thread
From: aron @ 2016-10-10 18:57 UTC (permalink / raw)
  To: linux-btrfs

Hi all,

I've been using btrfs for a few months now, without any problems. 
During work, I've noticed segfaults, when accessing my root directory. 
As my home directory contents was readable, I've decided to reboot. That 
was the worst decision, as now I can't copy my data off the SSD. It 
seems like a memory isse. I have backups, but its ~2 weeks old. What I 
did is a dd dump immediately. Have latest kernel and latest progs built 
from source now, but :S ...

This is what I've got:

When mounting:

BTRFS critical (device: sdb2): corrupt leaf, slot offset bad: 
block=610107392,root=1, slot=108

find-root prints nothing to the stdout ofter 2 hours.

running btrfs inspect-internal dump-tree -b 610107392 /dev/sdb2

leaf 610107392 items 188 free space 1690 generation 90792 owner 5
fs uuid 2cc75a87-b22b-448e-80d4-383a9f42deed
chunk uuid a5b09a2a-da3d-4049-91ba-4fe66932907b
	item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160
		inode generation 3 transid 90769 size 144 nbytes 16384
		block group 0 mode 40755 links 1 uid 0 gid 0
		rdev 0 flags 0x0(none)
	item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12
		inode ref index 0 namelen 2 name: ..
	item 2 key (256 DIR_ITEM 145260132) itemoff 16078 itemsize 33
		location key (265 INODE_ITEM 0) type DIR
		namelen 3 datalen 0 name: dev
	item 3 key (256 DIR_ITEM 217684952) itemoff 16045 itemsize 33
		location key (266 INODE_ITEM 0) type DIR
		namelen 3 datalen 0 name: run
	item 4 key (256 DIR_ITEM 308198373) itemoff 16011 itemsize 34
		location key (257 INODE_ITEM 0) type DIR

...
	item 111 key (261 DIR_ITEM 81211850) itemoff 11344 itemsize 131133
		location key (893669 INODE_ITEM 0) type FILE
		namelen 31 datalen 0 name: babl-0.1.16-1-x86_64.pkg.tar.xz
		location key (388547 INODE_ITEM 0) type FILE
		namelen 32 datalen 0 name: intltool-0.51.0-1-any.pkg.tar.xz
...
		namelen 30 datalen 0 name: glibc-2.24-2-x86_64.pkg.tar.xz
		location key (893658 INODE_ITEM 0) type FILE
		namelen 36 datalen 0 name: procps-ng-3.3.12-1-x86_64.pkg.tar.xz
		location key (EXTENT_TREE UNKNOWN.3 36094832640) type 12
		namelen 0 datalen 0 name:
		location key (291 UNKNOWN.0 0) type 0
		namelen 0 datalen 0 name:
		location key (18556457741975552 UNKNOWN.0 0) type 0
		namelen 0 datalen 7134 name:
		data
		location key (0 UNKNOWN.0 0) type 0
		namelen 0 datalen 0 name:
		location key (0 UNKNOWN.0 0) type 0
		namelen 0 datalen 0 name:
		location key (0 UNKNOWN.0 0) type 0
		namelen 0 datalen 0 name:
		location key (0 UNKNOWN.0 0) type 0
		namelen 0 datalen 0 name:
		location key (0 UNKNOWN.0 0) type 0
		namelen 0 datalen 0 name:
		location key (0 UNKNOWN.0 0) type 0
		namelen 0 datalen 0 name:
		location key (0 UNKNOWN.0 0) type 0
		namelen 0 datalen 0 name:
		location key (0 UNKNOWN.0 0) type 0
		namelen 0 datalen 0 name:
		location key (0 UNKNOWN.0 0) type 0
		namelen 0 datalen 0 name:

....

segfault


running restore:

incorrect offsets 11532 11548
Error searching -1

Tried every rescue, check commands, in different variations ... 
nothing. It seems that the root leaf (?) has some garbage, tried using 
the corrupt-block utility, to mark the item dirty got the same error: 
incorrect offsets.

The only thing I've managed is to restore a part of the /etc directory, 
with: btrfs restore -i -f 610123776 -vvvv -d /dev/sdb2 /mnt/restore

I'm still trying to learn how the data is structured now, but my 
problem is that I can't figure out how to calculate the leaf positions, 
using the dump-tree output ...

I need some kind tool/script that can recursively rescue the structure 
from a defined leaf. (can this be done?)

Any help would be appreciated! :)

Thanks!

Yours,
Aron


^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: corrupt leaf, slot offset bad
  2016-10-10 18:57 corrupt leaf, slot offset bad aron
@ 2016-10-10 21:03 ` Liu Bo
  2016-10-10 21:50   ` aron
  0 siblings, 1 reply; 6+ messages in thread
From: Liu Bo @ 2016-10-10 21:03 UTC (permalink / raw)
  To: aron; +Cc: linux-btrfs

On Mon, Oct 10, 2016 at 08:57:19PM +0200, aron@aron.ws wrote:
> Hi all,
> 
> I've been using btrfs for a few months now, without any problems. During
> work, I've noticed segfaults, when accessing my root directory. As my home
> directory contents was readable, I've decided to reboot. That was the worst
> decision, as now I can't copy my data off the SSD. It seems like a memory
> isse. I have backups, but its ~2 weeks old. What I did is a dd dump
> immediately. Have latest kernel and latest progs built from source now, but
> :S ...
> 
> This is what I've got:
> 
> When mounting:
> 
> BTRFS critical (device: sdb2): corrupt leaf, slot offset bad:
> block=610107392,root=1, slot=108

This indicates that leaf 610107392 is corrupted somehow because its slot
108's 'start offset in leaf' and slot 109's 'end offset in leaf' doesn't
match with each other, the cause is not shown though.

> 
> find-root prints nothing to the stdout ofter 2 hours.
> 
> running btrfs inspect-internal dump-tree -b 610107392 /dev/sdb2

> 
> leaf 610107392 items 188 free space 1690 generation 90792 owner 5

owner 5 means that it's not a tree root leaf, it's a fs tree leaf.

> fs uuid 2cc75a87-b22b-448e-80d4-383a9f42deed
> chunk uuid a5b09a2a-da3d-4049-91ba-4fe66932907b
> 	item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160
> 		inode generation 3 transid 90769 size 144 nbytes 16384
> 		block group 0 mode 40755 links 1 uid 0 gid 0
> 		rdev 0 flags 0x0(none)
> 	item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12
> 		inode ref index 0 namelen 2 name: ..
> 	item 2 key (256 DIR_ITEM 145260132) itemoff 16078 itemsize 33
> 		location key (265 INODE_ITEM 0) type DIR
> 		namelen 3 datalen 0 name: dev
> 	item 3 key (256 DIR_ITEM 217684952) itemoff 16045 itemsize 33
> 		location key (266 INODE_ITEM 0) type DIR
> 		namelen 3 datalen 0 name: run
> 	item 4 key (256 DIR_ITEM 308198373) itemoff 16011 itemsize 34
> 		location key (257 INODE_ITEM 0) type DIR
> 
> ...

Maybe we can check the content of item 108 and item 109 in this output from
'dump-tree'?

Thanks,

-liubo

> 	item 111 key (261 DIR_ITEM 81211850) itemoff 11344 itemsize 131133
> 		location key (893669 INODE_ITEM 0) type FILE
> 		namelen 31 datalen 0 name: babl-0.1.16-1-x86_64.pkg.tar.xz
> 		location key (388547 INODE_ITEM 0) type FILE
> 		namelen 32 datalen 0 name: intltool-0.51.0-1-any.pkg.tar.xz
> ...
> 		namelen 30 datalen 0 name: glibc-2.24-2-x86_64.pkg.tar.xz
> 		location key (893658 INODE_ITEM 0) type FILE
> 		namelen 36 datalen 0 name: procps-ng-3.3.12-1-x86_64.pkg.tar.xz
> 		location key (EXTENT_TREE UNKNOWN.3 36094832640) type 12
> 		namelen 0 datalen 0 name:
> 		location key (291 UNKNOWN.0 0) type 0
> 		namelen 0 datalen 0 name:
> 		location key (18556457741975552 UNKNOWN.0 0) type 0
> 		namelen 0 datalen 7134 name:
> 		data
> 		location key (0 UNKNOWN.0 0) type 0
> 		namelen 0 datalen 0 name:
> 		location key (0 UNKNOWN.0 0) type 0
> 		namelen 0 datalen 0 name:
> 		location key (0 UNKNOWN.0 0) type 0
> 		namelen 0 datalen 0 name:
> 		location key (0 UNKNOWN.0 0) type 0
> 		namelen 0 datalen 0 name:
> 		location key (0 UNKNOWN.0 0) type 0
> 		namelen 0 datalen 0 name:
> 		location key (0 UNKNOWN.0 0) type 0
> 		namelen 0 datalen 0 name:
> 		location key (0 UNKNOWN.0 0) type 0
> 		namelen 0 datalen 0 name:
> 		location key (0 UNKNOWN.0 0) type 0
> 		namelen 0 datalen 0 name:
> 		location key (0 UNKNOWN.0 0) type 0
> 		namelen 0 datalen 0 name:
> 
> ....
> 
> segfault
> 
> 
> running restore:
> 
> incorrect offsets 11532 11548
> Error searching -1
> 
> Tried every rescue, check commands, in different variations ... nothing. It
> seems that the root leaf (?) has some garbage, tried using the corrupt-block
> utility, to mark the item dirty got the same error: incorrect offsets.
> 
> The only thing I've managed is to restore a part of the /etc directory,
> with: btrfs restore -i -f 610123776 -vvvv -d /dev/sdb2 /mnt/restore
> 
> I'm still trying to learn how the data is structured now, but my problem is
> that I can't figure out how to calculate the leaf positions, using the
> dump-tree output ...
> 
> I need some kind tool/script that can recursively rescue the structure from
> a defined leaf. (can this be done?)
> 
> Any help would be appreciated! :)
> 
> Thanks!
> 
> Yours,
> Aron
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: corrupt leaf, slot offset bad
  2016-10-10 21:03 ` Liu Bo
@ 2016-10-10 21:50   ` aron
  2016-10-11 12:48     ` David Sterba
  0 siblings, 1 reply; 6+ messages in thread
From: aron @ 2016-10-10 21:50 UTC (permalink / raw)
  To: bo.li.liu; +Cc: linux-btrfs

Hi liubo,

item 109 has a few strange chars in its name (and it's truncated): 
1-x86_64.pkg.tar.xz 0x62 0x14 0x0a 0x0a

	item 105 key (261 DIR_ITEM 54556048) itemoff 11723 itemsize 72
		location key (606286 INODE_ITEM 0) type FILE
		namelen 42 datalen 0 name: python2-gobject-3.20.1-1-x86_64.pkg.tar.xz
	item 106 key (261 DIR_ITEM 56363628) itemoff 11660 itemsize 63
		location key (894298 INODE_ITEM 0) type FILE
		namelen 33 datalen 0 name: unrar-1:5.4.5-1-x86_64.pkg.tar.xz
	item 107 key (261 DIR_ITEM 66963651) itemoff 11600 itemsize 60
		location key (1178 INODE_ITEM 0) type FILE
		namelen 30 datalen 0 name: glibc-2.23-5-x86_64.pkg.tar.xz
	item 108 key (261 DIR_ITEM 68561395) itemoff 11532 itemsize 68
		location key (660578 INODE_ITEM 0) type FILE
		namelen 38 datalen 0 name: squashfs-tools-4.3-4-x86_64.pkg.tar.xz
	item 109 key (261 DIR_ITEM 76859450) itemoff 11483 itemsize 65
		location key (2397184 UNKNOWN.0 7091317839824617472) type 45
		namelen 13102 datalen 13358 name: 1-x86_64.pkg.tar.xzb\x14

		data
	item 110 key (261 DIR_ITEM 9799832789237604651) itemoff 11405 itemsize 
62
		location key (388547 INODE_ITEM 0) type FILE
		namelen 32 datalen 0 name: intltool-0.51.0-1-any.pkg.tar.xz
	item 111 key (261 DIR_ITEM 81211850) itemoff 11344 itemsize 131133
		location key (893669 INODE_ITEM 0) type FILE
		namelen 31 datalen 0 name: babl-0.1.16-1-x86_64.pkg.tar.xz
		location key (388547 INODE_ITEM 0) type FILE

Thanks,
Aron

On 2016-10-10 23:03, Liu Bo wrote:

> On Mon, Oct 10, 2016 at 08:57:19PM +0200, aron@aron.wswrote:
>
>> Hi all, I've been using btrfs for a few months now, without any
>> problems. During work, I've noticed segfaults, when accessing my 
>> root
>> directory. As my home directory contents was readable, I've decided 
>> to
>> reboot. That was the worst decision, as now I can't copy my data off
>> the SSD. It seems like a memory isse. I have backups, but its ~2 
>> weeks
>> old. What I did is a dd dump immediately. Have latest kernel and 
>> latest
>> progs built from source now, but :S ... This is what I've got: When
>> mounting: BTRFS critical (device: sdb2): corrupt leaf, slot offset 
>> bad:
>> block=610107392,root=1, slot=108
>
> This indicates that leaf 610107392 is corrupted somehow because its 
> slot
> 108's 'start offset in leaf' and slot 109's 'end offset in leaf' 
> doesn't
> match with each other, the cause is not shown though.
>
>> find-root prints nothing to the stdout ofter 2 hours. running btrfs
>> inspect-internal dump-tre> 92 /dev/sdb2 leaf 610107392 items 188 
>> free
> spac
> tion 90792 owner 5
>
> owner 5 means that it's not a tree root leaf, > ee leaf. fs uuid
> 2cc75a87-b22b-448e-80d4-383a9f42deed chunk uuid
>> a5b09a2a-da3d-4049-91ba-4fe66932907b item 0 key (256 INODE_ITEM 0)
>> itemoff 16123 itemsize 160 inode generation 3 transid 90769 size 144
>> nbytes 16384 block group 0 mode 40755 links 1 uid 0 gid 0 rdev 0 
>> flags
>> 0x0(none) item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12
>> inode ref index 0 namelen 2 name: .. item 2 key (256 DIR_ITEM
>> 145260132) itemoff 16078 itemsize 33 location key (265 INODE_ITEM 0)
>> type DIR namelen 3 datalen 0 name: dev item 3 key (256 DIR_ITEM
>> 217684952) itemoff 16045 itemsize 33 location key (266 INODE_ITEM 0)
>> type DIR namelen 3 datalen 0 name: run item 4 key (256 DIR_ITEM
>> 308198373) itemoff 16011 itemsize 34 location key (257
> ) type DIR ...
>
> Maybe we can check the content of item 108 and item 109 in this 
> output
> from
> 'dump-tree'?
>
> Thanks,
>
> -liubo
>
>> item 111 key (261 DIR_ITEM 81211850) itemoff 11344 itemsize 131133
>> location key (893669 INODE_ITEM 0) type FILE namelen 31 datalen 0 
>> name:
>> babl-0.1.16-1-x86_64.pkg.tar.xz location key (388547 INODE_ITEM 0) 
>> type
>> FILE namelen 32 datalen 0 name: intltool-0.51.0-1-any.pkg.tar.xz ...
>> namelen 30 datalen 0 name: glibc-2.24-2-x86_64.pkg.tar.xz location 
>> key
>> (893658 INODE_ITEM 0) type FILE namelen 36 datalen 0 name:
>> procps-ng-3.3.12-1-x86_64.pkg.tar.xz location key (EXTENT_TREE
>> UNKNOWN.3 36094832640) type 12 namelen 0 datalen 0 name: location 
>> key
>> (291 UNKNOWN.0 0) type 0 namelen 0 datalen 0 name: location key
>> (18556457741975552 UNKNOWN.0 0) type 0 namelen 0 datalen 7134 name:
>> data location key (0 UNKNOWN.0 0) type 0 namelen 0 datalen 0 name:
>> location key (0 UNKNOWN.0 0) type 0 namelen 0 datalen 0 name: 
>> location
>> key (0 UNKNOWN.0 0) type 0 namelen 0 datalen 0 name: location key (0
>> UNKNOWN.0 0) type 0 namelen 0 datalen 0 name: location key (0 
>> UNKNOWN.0
>> 0) type 0 namelen 0 datalen 0 name: location key (0 UNKNOWN.0 0) 
>> type 0
>> namelen 0 datalen 0 name: location key (0 UNKNOWN.0 0) type 0 
>> namelen 0
>> datalen 0 name: location key (0 UNKNOWN.0 0) type 0 namelen 0 
>> datalen 0
>> name: location key (0 UNKNOWN.0 0) type 0 namelen 0 datalen 0 name:
>> .... segfault running restore: incorrect offsets 11532 11548 Error
>> searching -1 Tried every rescue, check commands, in different
>> variations ... nothing. It seems that the root leaf (?) has some
>> garbage, tried using the corrupt-block utility, to mark the item 
>> dirty
>> got the same error: incorrect offsets. The only thing I've managed 
>> is
>> to restore a part of the /etc directory, with: btrfs restore -i -f
>> 610123776 -vvvv -d /dev/sdb2 /mnt/restore I'm still trying to learn 
>> how
>> the data is structured now, but my problem is that I can't figure 
>> out
>> how to calculate the leaf positions, using the dump-tree output ... 
>> I
>> need some kind tool/script that can recursively rescue the structure
>> from a defined leaf. (can this be done?) Any help would be 
>> appreciated!
>> :) Thanks! Yours, Aron -- To unsubscribe from this list: send the 
>> line
>> "unsubscribe linux-btrfs" in the body of a message to
>> majordomo@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html [1]
>
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html [1]



Links:
------
[1] http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: corrupt leaf, slot offset bad
  2016-10-10 21:50   ` aron
@ 2016-10-11 12:48     ` David Sterba
  2016-10-11 14:09       ` Liu Bo
  0 siblings, 1 reply; 6+ messages in thread
From: David Sterba @ 2016-10-11 12:48 UTC (permalink / raw)
  To: aron; +Cc: bo.li.liu, linux-btrfs

Hi,

looks like a lot of random bitflips.

On Mon, Oct 10, 2016 at 11:50:14PM +0200, aron@aron.ws wrote:
> item 109 has a few strange chars in its name (and it's truncated): 
> 1-x86_64.pkg.tar.xz 0x62 0x14 0x0a 0x0a
> 
> 	item 105 key (261 DIR_ITEM 54556048) itemoff 11723 itemsize 72
> 		location key (606286 INODE_ITEM 0) type FILE
> 		namelen 42 datalen 0 name: python2-gobject-3.20.1-1-x86_64.pkg.tar.xz
> 	item 106 key (261 DIR_ITEM 56363628) itemoff 11660 itemsize 63
> 		location key (894298 INODE_ITEM 0) type FILE
> 		namelen 33 datalen 0 name: unrar-1:5.4.5-1-x86_64.pkg.tar.xz
> 	item 107 key (261 DIR_ITEM 66963651) itemoff 11600 itemsize 60
> 		location key (1178 INODE_ITEM 0) type FILE
> 		namelen 30 datalen 0 name: glibc-2.23-5-x86_64.pkg.tar.xz
> 	item 108 key (261 DIR_ITEM 68561395) itemoff 11532 itemsize 68
> 		location key (660578 INODE_ITEM 0) type FILE
> 		namelen 38 datalen 0 name: squashfs-tools-4.3-4-x86_64.pkg.tar.xz
> 	item 109 key (261 DIR_ITEM 76859450) itemoff 11483 itemsize 65
> 		location key (2397184 UNKNOWN.0 7091317839824617472) type 45
> 		namelen 13102 datalen 13358 name: 1-x86_64.pkg.tar.xzb\x14

namelen must be smaller than 255, but the number itself does not look
like a bitflip (0x332e), the name looks like a fragment of.

The location key is random garbage, likely an overwritten memory,
7091317839824617472 == 0x62696c0100230000 contains ascii 'bil', the key
type is unknown but should be INODE_ITEM.

> 		data
> 	item 110 key (261 DIR_ITEM 9799832789237604651) itemoff 11405 itemsize 
> 62
> 		location key (388547 INODE_ITEM 0) type FILE
> 		namelen 32 datalen 0 name: intltool-0.51.0-1-any.pkg.tar.xz
> 	item 111 key (261 DIR_ITEM 81211850) itemoff 11344 itemsize 131133

itemsize 131133 == 0x2003d is a clear bitflip, 0x3d == 61, corresponds
to the expected item size.

There's possibly other random bitflips in the keys or other structures.
It's hard to estimate the damage and thus the scope of restorable data.

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: corrupt leaf, slot offset bad
  2016-10-11 12:48     ` David Sterba
@ 2016-10-11 14:09       ` Liu Bo
  2016-11-14 20:28         ` Kai Krakow
  0 siblings, 1 reply; 6+ messages in thread
From: Liu Bo @ 2016-10-11 14:09 UTC (permalink / raw)
  To: dsterba; +Cc: aron, linux-btrfs

On Tue, Oct 11, 2016 at 02:48:09PM +0200, David Sterba wrote:
> Hi,
> 
> looks like a lot of random bitflips.
> 
> On Mon, Oct 10, 2016 at 11:50:14PM +0200, aron@aron.ws wrote:
> > item 109 has a few strange chars in its name (and it's truncated): 
> > 1-x86_64.pkg.tar.xz 0x62 0x14 0x0a 0x0a
> > 
> > 	item 105 key (261 DIR_ITEM 54556048) itemoff 11723 itemsize 72
> > 		location key (606286 INODE_ITEM 0) type FILE
> > 		namelen 42 datalen 0 name: python2-gobject-3.20.1-1-x86_64.pkg.tar.xz
> > 	item 106 key (261 DIR_ITEM 56363628) itemoff 11660 itemsize 63
> > 		location key (894298 INODE_ITEM 0) type FILE
> > 		namelen 33 datalen 0 name: unrar-1:5.4.5-1-x86_64.pkg.tar.xz
> > 	item 107 key (261 DIR_ITEM 66963651) itemoff 11600 itemsize 60
> > 		location key (1178 INODE_ITEM 0) type FILE
> > 		namelen 30 datalen 0 name: glibc-2.23-5-x86_64.pkg.tar.xz
> > 	item 108 key (261 DIR_ITEM 68561395) itemoff 11532 itemsize 68
> > 		location key (660578 INODE_ITEM 0) type FILE
> > 		namelen 38 datalen 0 name: squashfs-tools-4.3-4-x86_64.pkg.tar.xz
> > 	item 109 key (261 DIR_ITEM 76859450) itemoff 11483 itemsize 65
> > 		location key (2397184 UNKNOWN.0 7091317839824617472) type 45
> > 		namelen 13102 datalen 13358 name: 1-x86_64.pkg.tar.xzb\x14
> 
> namelen must be smaller than 255, but the number itself does not look
> like a bitflip (0x332e), the name looks like a fragment of.
> 
> The location key is random garbage, likely an overwritten memory,
> 7091317839824617472 == 0x62696c0100230000 contains ascii 'bil', the key
> type is unknown but should be INODE_ITEM.
> 
> > 		data
> > 	item 110 key (261 DIR_ITEM 9799832789237604651) itemoff 11405 itemsize 
> > 62
> > 		location key (388547 INODE_ITEM 0) type FILE
> > 		namelen 32 datalen 0 name: intltool-0.51.0-1-any.pkg.tar.xz
> > 	item 111 key (261 DIR_ITEM 81211850) itemoff 11344 itemsize 131133
> 
> itemsize 131133 == 0x2003d is a clear bitflip, 0x3d == 61, corresponds
> to the expected item size.
> 
> There's possibly other random bitflips in the keys or other structures.
> It's hard to estimate the damage and thus the scope of restorable data.

It makes sense since this's a ssd we may have only one copy for metadata.

Thanks,

-liubo

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: corrupt leaf, slot offset bad
  2016-10-11 14:09       ` Liu Bo
@ 2016-11-14 20:28         ` Kai Krakow
  0 siblings, 0 replies; 6+ messages in thread
From: Kai Krakow @ 2016-11-14 20:28 UTC (permalink / raw)
  To: linux-btrfs

Am Tue, 11 Oct 2016 07:09:49 -0700
schrieb Liu Bo <bo.li.liu@oracle.com>:

> On Tue, Oct 11, 2016 at 02:48:09PM +0200, David Sterba wrote:
> > Hi,
> > 
> > looks like a lot of random bitflips.
> > 
> > On Mon, Oct 10, 2016 at 11:50:14PM +0200, aron@aron.ws wrote:  
> > > item 109 has a few strange chars in its name (and it's
> > > truncated): 1-x86_64.pkg.tar.xz 0x62 0x14 0x0a 0x0a
> > > 
> > > 	item 105 key (261 DIR_ITEM 54556048) itemoff 11723
> > > itemsize 72 location key (606286 INODE_ITEM 0) type FILE
> > > 		namelen 42 datalen 0 name:
> > > python2-gobject-3.20.1-1-x86_64.pkg.tar.xz item 106 key (261
> > > DIR_ITEM 56363628) itemoff 11660 itemsize 63 location key (894298
> > > INODE_ITEM 0) type FILE namelen 33 datalen 0 name:
> > > unrar-1:5.4.5-1-x86_64.pkg.tar.xz item 107 key (261 DIR_ITEM
> > > 66963651) itemoff 11600 itemsize 60 location key (1178 INODE_ITEM
> > > 0) type FILE namelen 30 datalen 0 name:
> > > glibc-2.23-5-x86_64.pkg.tar.xz item 108 key (261 DIR_ITEM
> > > 68561395) itemoff 11532 itemsize 68 location key (660578
> > > INODE_ITEM 0) type FILE namelen 38 datalen 0 name:
> > > squashfs-tools-4.3-4-x86_64.pkg.tar.xz item 109 key (261 DIR_ITEM
> > > 76859450) itemoff 11483 itemsize 65 location key (2397184
> > > UNKNOWN.0 7091317839824617472) type 45 namelen 13102 datalen
> > > 13358 name: 1-x86_64.pkg.tar.xzb\x14  
> > 
> > namelen must be smaller than 255, but the number itself does not
> > look like a bitflip (0x332e), the name looks like a fragment of.
> > 
> > The location key is random garbage, likely an overwritten memory,
> > 7091317839824617472 == 0x62696c0100230000 contains ascii 'bil', the
> > key type is unknown but should be INODE_ITEM.
> >   
> > > 		data
> > > 	item 110 key (261 DIR_ITEM 9799832789237604651) itemoff
> > > 11405 itemsize 62
> > > 		location key (388547 INODE_ITEM 0) type FILE
> > > 		namelen 32 datalen 0 name:
> > > intltool-0.51.0-1-any.pkg.tar.xz item 111 key (261 DIR_ITEM
> > > 81211850) itemoff 11344 itemsize 131133  
> > 
> > itemsize 131133 == 0x2003d is a clear bitflip, 0x3d == 61,
> > corresponds to the expected item size.
> > 
> > There's possibly other random bitflips in the keys or other
> > structures. It's hard to estimate the damage and thus the scope of
> > restorable data.  
> 
> It makes sense since this's a ssd we may have only one copy for
> metadata.
> 
> Thanks,
> 
> -liubo

>From this point of view it doesn't make sense to store only one copy of
meta data on SSD... The bit flip probably happened in RAM when taking
the other garbage into account, so dup meta data could have helped here.

If the SSD firmware would collapse duplicate meta data into single
blobs, that's perfectly fine. If the dup meta data arrives with bits
flipped, it won't be deduplicated. So this is fine, too.

BTW: I cannot believe that SSD firmwares really do the quite expensive
job of deduplication other than maybe internal compression. Maybe there
are some drives out there but most won't deduplicate. It's just too
little gain for too much complexity. So I personally would always
switch on duplicate meta data even for SSD. It shouldn't add to wear
leveling too much if you do the usual SSD optimization anyways (like
noatime).

PS: I suggest doing an extensive memtest86 before trying any repairs on
this system... Are you probably mixing different model DIMMs in dual
channel slots? Most of the times I've seen bitflips, this was the
culprit...

-- 
Regards,
Kai

Replies to list-only preferred.



^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-11-14 20:29 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-10 18:57 corrupt leaf, slot offset bad aron
2016-10-10 21:03 ` Liu Bo
2016-10-10 21:50   ` aron
2016-10-11 12:48     ` David Sterba
2016-10-11 14:09       ` Liu Bo
2016-11-14 20:28         ` Kai Krakow

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).