linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Mike Gilbert <floppymaster@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Unable to remove directory entry
Date: Mon, 9 Dec 2019 10:20:33 +0800	[thread overview]
Message-ID: <5506e5de-a9f8-4830-8172-c07343da4218@gmx.com> (raw)
In-Reply-To: <d954ccdb-ac9a-1209-130c-e3b34e4a7a45@gmx.com>


[-- Attachment #1.1: Type: text/plain, Size: 3667 bytes --]



On 2019/12/9 上午10:05, Qu Wenruo wrote:
> 
> 
> On 2019/12/9 上午9:51, Mike Gilbert wrote:
> [...]
>>
>> Here you go.
>>
>> I ran this while the filesystem was mounted; if you need it to be run
>> while offline, I'll have to fire up a livecd.
> The info is good enough, no need to go livecd.
> 
>> --
>>        item 6 key (4065004 INODE_ITEM 0) itemoff 15158 itemsize 160
>>                generation 21397 transid 21397 size 12261 nbytes 12288
>>                block group 0 mode 100644 links 1 uid 250 gid 250 rdev 0
>>                sequence 23 flags 0x0(none)
>>                atime 1565546668.383680243 (2019-08-11 14:04:28)
>>                ctime 1565546668.383680243 (2019-08-11 14:04:28)
>>                mtime 1565546668.383680243 (2019-08-11 14:04:28)
>>                otime 1565546668.336681213 (2019-08-11 14:04:28)
>>        item 7 key (4065004 INODE_REF 486836) itemoff 15104 itemsize 54
>>                index 13905 namelen 44 name:
>> 0390cb341d248c589c419007da68b2-7351.manifest
> 
> That inode exists and is good.
> 
>>        item 8 key (4065004 EXTENT_DATA 0) itemoff 15051 itemsize 53
>>                generation 21397 type 1 (regular)
>>                extent data disk byte 6288928768 nr 12288
>>                extent data offset 0 nr 12288 ram 12288
>>                extent compression 0 (none)
>>        item 9 key (4210974 INODE_ITEM 0) itemoff 14891 itemsize 160
>>        item 63 key (486836 DIR_INDEX 13905) itemoff 6199 itemsize 74
>>                location key (4065004 INODE_ITEM 0) type FILE
>>                transid 21397 data_len 0 name_len 44
>>                name: 0390cb341d248c589c419007da68b2-7351.manifest
> 
> Good parent dir index.
> 
>> leaf 533498265600 items 128 free space 6682 generation 176439 owner FS_TREE
>> leaf 533498265600 flags 0x1(WRITTEN) backref revision 1
>> fs uuid 5e9dcab6-036d-40f1-8b40-24ab4c062bf6
>> chunk uuid 0be705de-5d3b-4c23-979e-d7aaad224cfb
>>        item 62 key (486836 DIR_ITEM 2543451757) itemoff 6273 itemsize 74
>>                location key (4065004 INODE_ITEM 1073741824) type FILE
>>                transid 21397 data_len 0 name_len 44
>>                name: 0390cb341d248c589c419007da68b2-7351.manifest
> 
> This is the problem, bad parent dir hash.
> 
> The key should be (4065004 INODE_ITEM 0). The 1073741824 (0x40000000) is
> completely garbage.
> 
> That garbage looks like a bit flip at runtime.
> It's recommended to check your memory.
> 
> I'll add extra tree-check checks, so that such runtime problem can be
> detected before corrupted data reach disk.
> 
> 
> For repair, I'll craft a special btrfs-progs for you to handle it, as
> that should be the safest way.
> Please wait for another 15min for that tool.

Here is the special branch for you:
https://github.com/adam900710/btrfs-progs/tree/dirty_fix_for_mike

After compile, you can use btrfs-corrupt-block (I know it's a bad name)
to repair your fs (must be unmounted):

# ./btrfs-corrupt-block -X /dev/sda3

If anything wrong happened, your fs should be kept untouched.
If repaired successfully, there should be no output.

Thanks,
Qu

> 
> Thanks,
> Qu
> 
> 
>>        item 63 key (486836 DIR_INDEX 13905) itemoff 6199 itemsize 74
>>                location key (4065004 INODE_ITEM 0) type FILE
>>                transid 21397 data_len 0 name_len 44
>>                name: 0390cb341d248c589c419007da68b2-7351.manifest
>> parent transid verify failed on 629293056 wanted 177041 found 177044
>> parent transid verify failed on 629293056 wanted 177041 found 177044
>> Ignoring transid failure
>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-12-09  2:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-08 19:19 Unable to remove directory entry Mike Gilbert
2019-12-09  0:11 ` Qu Wenruo
2019-12-09  0:30   ` Mike Gilbert
2019-12-09  0:41     ` Qu Wenruo
2019-12-09  1:31       ` Mike Gilbert
2019-12-09  1:45         ` Qu Wenruo
2019-12-09  1:51           ` Mike Gilbert
2019-12-09  2:05             ` Qu Wenruo
2019-12-09  2:20               ` Qu Wenruo [this message]
2019-12-09  2:37                 ` Mike Gilbert
2019-12-09  2:43                   ` Qu Wenruo
2019-12-09  0:17 ` Zygo Blaxell
2019-12-09  1:33   ` Zygo Blaxell
2019-12-09  1:52     ` Qu Wenruo
2019-12-09  2:23       ` Zygo Blaxell

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=5506e5de-a9f8-4830-8172-c07343da4218@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=floppymaster@gmail.com \
    --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).