Re: Unable to remove directory entry

From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Mike Gilbert <floppymaster@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: Unable to remove directory entry
Date: Mon, 9 Dec 2019 08:11:00 +0800	[thread overview]
Message-ID: <5eae7d6d-a462-53f4-df0c-3b273426e2b2@gmx.com> (raw)
In-Reply-To: <CAJ0EP41toGSPQwB4Ys4aNzGGJNDBS-NHgPOcGanBk6d6Nn_LWw@mail.gmail.com>

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

On 2019/12/9 上午3:19, Mike Gilbert wrote:
> Hello,
> 
> I have a directory entry that cannot be stat-ed or unlinked. This
> issue persists across reboots, so it seems there is something wrong on
> disk.
> 
> % ls -l /var/cache/ccache.bad/2/c
> ls: cannot access
> '/var/cache/ccache.bad/2/c/0390cb341d248c589c419007da68b2-7351.manifest':
> No such
> file or directory
> total 0
> -????????? ? ? ? ?            ? 0390cb341d248c589c419007da68b2-7351.manifest

Dmesg if any, please.

> 
> % uname -a
> Linux naomi 4.19.67 #4 SMP Sun Aug 18 14:35:39 EDT 2019 x86_64 AMD
> Phenom(tm) II X6 1055T Processor
> AuthenticAMD GNU/Linux

The kernel is not new enough to btrfs' standard.

For this possibility name hash mismatch bug, newer kernel will reported
detailed problems.

> 
> % btrfs --version
> btrfs-progs v5.4
> 
> I have tried running btrfs check, and I get differing results based on
> the --mode switch:
> 
> # btrfs check --readonly /dev/sda3
> [1/7] checking root items
> [2/7] checking extents
> [3/7] checking free space cache
> [4/7] checking fs roots
> [5/7] checking only csums items (without verifying data)
> [6/7] checking root refs
> [7/7] checking quota groups
> Opening filesystem to check...
> Checking filesystem on /dev/sda3
> UUID: 5e9dcab6-036d-40f1-8b40-24ab4c062bf6
> found 284337733632 bytes used, no error found
> total csum bytes: 267182280
> total tree bytes: 4498915328
> total fs tree bytes: 3972464640
> total extent tree bytes: 199819264
> btree space waste bytes: 776711635
> file data blocks allocated: 313928671232
>  referenced 279141621760
> 
> # btrfs check --readonly --mode=lowmem /dev/sda3
> [1/7] checking root items
> [2/7] checking extents
> [3/7] checking free space cache
> [4/7] checking fs roots
> ERROR: root 5 INODE_ITEM[4065004] index 18446744073709551615 name
> 0390cb341d248c589c419007da68b2-7351.manifest filetype 1 missing
> ERROR: root 5 DIR ITEM[486836 13905] name
> 0390cb341d248c589c419007da68b2-7351.manifest filetype 1 mismath
> ERROR: root 5 DIR ITEM[486836 2543451757] mismatch name
> 0390cb341d248c589c419007da68b2-7351.manifest filetype 1

This means the name hash for the filename
"0390cb341d248c589c419007da68b2-7351.manifest" is incorrect.

Thus kernel can't locate that inode correctly.

Furthermore, the index for inode 4065004 doesn't make much sense. The
number looks absolutely insane.

If your fs is small enough, you can try do a binary dump first, then try
btrfs check --mode=lowmem --repair, as we had such ability to repair in
v5.4.

If your fs is too large, I guess you can only prey bad thing doesn't
happen...

Thanks,
Qu

> ERROR: errors found in fs roots
> Opening filesystem to check...
> Checking filesystem on /dev/sda3
> UUID: 5e9dcab6-036d-40f1-8b40-24ab4c062bf6
> found 284337733632 bytes used, error(s) found
> total csum bytes: 267182280
> total tree bytes: 4498915328
> total fs tree bytes: 3972464640
> total extent tree bytes: 199819264
> btree space waste bytes: 776711635
> file data blocks allocated: 313928671232
>  referenced 279141621760
> 
> Please advise on possible next steps to diagnose and fix this.
> 

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