All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Nesbitt <nesbittmeister@gmail.com>
To: Hugo Mills <hugo@carfax.org.uk>,
	Stephen Nesbitt <snesbitt@aussieswithtails.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: Seeking Help on Corruption Issues
Date: Tue, 3 Oct 2017 15:49:25 -0700	[thread overview]
Message-ID: <e531fc75-8080-eb82-86bb-2f787bf0ea43@gmail.com> (raw)
In-Reply-To: <20171003211121.GF3293@carfax.org.uk>


On 10/3/2017 2:11 PM, Hugo Mills wrote:
>     Hi, Stephen,
>
> On Tue, Oct 03, 2017 at 08:52:04PM +0000, Stephen Nesbitt wrote:
>> Here it i. There are a couple of out-of-order entries beginning at 117. And
>> yes I did uncover a bad stick of RAM:
>>
>> btrfs-progs v4.9.1
>> leaf 2589782867968 items 134 free space 6753 generation 3351574 owner 2
>> fs uuid 24b768c3-2141-44bf-ae93-1c3833c8c8e3
>> chunk uuid 19ce12f0-d271-46b8-a691-e0d26c1790c6
> [snip]
>> item 116 key (1623012749312 EXTENT_ITEM 45056) itemoff 10908 itemsize 53
>> extent refs 1 gen 3346444 flags DATA
>> extent data backref root 271 objectid 24999978 offset 0 count 1
>> item 117 key (1621939052544 EXTENT_ITEM 8192) itemoff 10855 itemsize 53
>> extent refs 1 gen 3346495 flags DATA
>> extent data backref root 271 objectid 21751764 offset 6733824 count 1
>> item 118 key (1623012450304 EXTENT_ITEM 8192) itemoff 10802 itemsize 53
>> extent refs 1 gen 3351513 flags DATA
>> extent data backref root 271 objectid 5724364 offset 680640512 count 1
>> item 119 key (1623012802560 EXTENT_ITEM 12288) itemoff 10749 itemsize 53
>> extent refs 1 gen 3346376 flags DATA
>> extent data backref root 271 objectid 21751764 offset 6701056 count 1
>>>> hex(1623012749312)
> '0x179e3193000'
>>>> hex(1621939052544)
> '0x179a319e000'
>>>> hex(1623012450304)
> '0x179e314a000'
>>>> hex(1623012802560)
> '0x179e31a0000'
>
>     That's "e" -> "a" in the fourth hex digit, which is a single-bit
> flip, and should be fixable by btrfs check (I think). However, even
> fixing that, it's not ordered, because 118 is then before 117, which
> could be another bitflip ("9" -> "4" in the 7th digit), but two bad
> bits that close to each other seems unlikely to me.
>
>     Hugo.

Hope this is a duplicate reply - I might have fat fingered something.

The underlying file is disposable/replaceable. Any way to zero out/zap 
the bad BTRFS entry?

-steve


  reply	other threads:[~2017-10-03 22:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-03 20:06 Seeking Help on Corruption Issues Stephen Nesbitt
2017-10-03 20:10 ` Hugo Mills
     [not found]   ` <CAPXGFsE4HzGWhjKtp=E-4LN_-vQnFtqJDDhTva9Wkg9Gtm9D_w@mail.gmail.com>
2017-10-03 21:11     ` Hugo Mills
2017-10-03 22:49       ` Stephen Nesbitt [this message]
2017-10-04 22:19         ` Hugo Mills

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=e531fc75-8080-eb82-86bb-2f787bf0ea43@gmail.com \
    --to=nesbittmeister@gmail.com \
    --cc=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=snesbitt@aussieswithtails.com \
    /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.