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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.