On 2019/8/15 下午5:41, Jim Geo wrote:
> Στις Πέμ, 15 Αυγ 2019 στις 12:12 μ.μ., ο/η Qu Wenruo
> <quwenruo.btrfs@xxxxxxx> έγραψε:
>>
>>
>>
>> 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:
signature.asc
Description: OpenPGP digital signature
