From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Jim Geo <dim.geo@gmail.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs corruption: invalid mode: has 00 expect valid S_IF* bit(s)
Date: Thu, 15 Aug 2019 17:57:01 +0800 [thread overview]
Message-ID: <b8375f78-6caa-3d32-8b6b-027cd0da6c9f@gmx.com> (raw)
In-Reply-To: <CAD9MmSc-ZELTEMbuHZfB8=wEnnrYwo6CAn5F4fz2tNhw6FGy5w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4060 bytes --]
On 2019/8/15 下午5:41, Jim Geo wrote:
> Στις Πέμ, 15 Αυγ 2019 στις 12:12 μ.μ., ο/η Qu Wenruo
> <quwenruo.btrfs@gmx.com> έγραψε:
>>
>>
>>
>> On 2019/8/15 下午4:39, Jim Geo wrote:
>>> Hello,
>>>
>>> my /home folder is on a single device btrfs partition.
>>> When I ls a directory, I get these messages on ls:
>>> ls: cannot access 'file1' : Input/output error
>>> ls: cannot access 'file2' : Input/output error
>>> ls: cannot access 'file3' : Input/output error
>>>
>>> and dmesg says:
>>> [31209.938486] BTRFS critical (device sdd1): corrupt leaf: root=5
>>> block=859701248 slot=93 ino=5830829, invalid mode: has 00 expect valid
>>> S_IF* bit(s)
>>
>> Please provide the dump of that tree blocks.
>>
>> # btrfs ins dump-tree -b 859701248 /dev/sdd1
>>
>> It looks like that tree block has something wrong with it.
>> Thus kernel reject to accept the data.
> Hello,
>
> Attached you can find the dump.
> I changed some filenames for privacy but the filenames that came from
> the dump are the ones that ls says that are problematic.
Forgot to mention that, feel free to censor the filenames.
And it turns out that, it's indeed a corruption.
item 93 key (5830829 INODE_ITEM 0) itemoff 5613 itemsize 160
generation 99667 transid 99669 size 0 nbytes 0
block group 0 mode 0 links 1 uid 0 gid 0 rdev 0
sequence 2 flags 0x0(none)
atime 0.0 (1970-01-01 02:00:00)
ctime 1516386417.601932603 (2018-01-19 20:26:57)
mtime 0.0 (1970-01-01 02:00:00)
otime 0.0 (1970-01-01 02:00:00)
item 94 key (5830829 INODE_REF 376204) itemoff 5584 itemsize 29
index 61648 namelen 19 name: <censored>
First, it's an empty file without any S_IFMT flag.
I believe it's a regular file, but it's created very recently.
You can try to remove that file with older kernel (before v5.2 should
not trigger such problem).
Then the problem should be solved.
But please consider double check your memory, as it looks like a memory
bitflip or even corruption.
And also, please consider do a btrfs check --readonly to see if there is
any other problem.
Thanks,
Qu
>
> Thanks a lot!
>>
>> [...]
>>>
>>> I scrubbed the filesystem but no errors were detected/fixed.
>>
>> Scrub mostly only verify checksum, doesn't care about the data in the
>> tree blocks.
>>
>>>
>>> btrfs scrub status /home:
>>> scrub status for myuuid
>>> scrub started at Thu Aug 15 02:24:42 2019 and finished after 03:55:12
>>> total bytes scrubbed: 2.05TiB with 0 errors
>>>
>>> uname -a:
>>> Linux gentoo 5.2.8-ck #1 SMP PREEMPT Wed Aug 14 20:44:33 EEST 2019
>>> x86_64 Intel(R) Core(TM) i5-4460 CPU @ 3.20GHz GenuineIntel GNU/Linux
>>>
>>> btrfs --version:
>>> btrfs-progs v4.19
>>>
>>> btrfs fi show:
>>> Label: 'home_btrfs' uuid:-------
>>> Total devices 1 FS bytes used 2.04TiB
>>> devid 1 size 2.13TiB used 2.13TiB path /dev/sdd1
>>>
>>> btrfs fi df /home:
>>> Data, single: total=2.12TiB, used=2.04TiB
>>> System, DUP: total=64.00MiB, used=256.00KiB
>>> Metadata, DUP: total=7.00GiB, used=4.48GiB
>>> GlobalReserve, single: total=512.00MiB, used=0.00B
>>>
>>> btrfs device stats /home:
>>> [/dev/sdd1].write_io_errs 4
>>> [/dev/sdd1].read_io_errs 3
>>> [/dev/sdd1].flush_io_errs 0
>>> [/dev/sdd1].corruption_errs 0
>>> [/dev/sdd1].generation_errs 0
>>>
>>> mount options:
>>> /dev/sdd1 on /home type btrfs
>>> (rw,relatime,space_cache,autodefrag,subvolid=5,subvol=/)
>>>
>>> How can I fix this corruption? How can I detect if more
>>> files/directories are affected?
>>
>> Affected inode number is 5830829. But I need to above mentioned dump to
>> make sure if it's not a false alert.
>>
>> If it's truely corrupted by whatever the reason, you'd
>> better check your memory, as it looks like a bit flip.
>>
>> Thanks,
>> Qu
>>>
>>> Kind Regards,
>>> Jim
>>>
>>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2019-08-15 9:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-15 8:39 btrfs corruption: invalid mode: has 00 expect valid S_IF* bit(s) Jim Geo
2019-08-15 9:12 ` Qu Wenruo
[not found] ` <CAD9MmSc-ZELTEMbuHZfB8=wEnnrYwo6CAn5F4fz2tNhw6FGy5w@mail.gmail.com>
2019-08-15 9:57 ` Qu Wenruo [this message]
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=b8375f78-6caa-3d32-8b6b-027cd0da6c9f@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=dim.geo@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