* 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).