From: Liu Bo <bo.li.liu@oracle.com>
To: dsterba@suse.cz
Cc: aron@aron.ws, linux-btrfs@vger.kernel.org
Subject: Re: corrupt leaf, slot offset bad
Date: Tue, 11 Oct 2016 07:09:49 -0700 [thread overview]
Message-ID: <20161011140949.GA5284@localhost.localdomain> (raw)
In-Reply-To: <20161011124809.GN11398@twin.jikos.cz>
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
next prev parent reply other threads:[~2016-10-11 14:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2016-11-14 20:28 ` Kai Krakow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161011140949.GA5284@localhost.localdomain \
--to=bo.li.liu@oracle.com \
--cc=aron@aron.ws \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).