On Tue, Oct 03, 2017 at 03:49:25PM -0700, Stephen Nesbitt wrote:
>
> 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?Not really. Even trying to delete the related file(s), it's going to fall over when reading the metadata in in the first place. (The key order check is a metadata invariant, like the csum checks and transid checks). At best, you'd have to get btrfs check to fix it. It should be able to manage a single-bit error, but you've got two single-bit errors in close proximity, and I'm not sure it'll be able to deal with it. Might be worth trying it. The FS _might_ blow up as a result of an attempted fix, but you say it's replacable, so that's kind of OK. The worst I'd _expect_ to happen with btrfs check --repair is that it just won't be able to deal with it and you're left where you started. Go for it. Hugo. -- Hugo Mills | You shouldn't anthropomorphise computers. They hugo@... carfax.org.uk | really don't like that. http://carfax.org.uk/ | PGP: E2AB1DE4 |
signature.asc
Description: Digital signature
