Re: btrfs errors

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

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



On 2019/8/13 下午5:48, Konstantin V. Gavrilenko wrote:
> Hi list
> 
> I have run the btrfs check, and that reported multiple errors on the FS.
> 
> # btrfs check --readonly --force /dev/kubuntu-vg/lv_root
> <SKIP>

Please don't skip the output, especially for btrfs check.

The first tree btrfs check checks is extent tree, if we have anything
wrong in extent tree, it's way serious than the later part.

And I understand you want to check your root fs, thus you have to use
--force, but I'd recommend to go whatever distro you like, use its
liveCD/USB to check your root fs.

It looks like that since your fs is still mounted, the data structure
changed during the btrfs check run, it's possible to cause false alert.

> root 9214 inode 6850330 errors 2001, no inode item, link count wrong
>         unresolved ref dir 266982 index 22459 namelen 36 name 9621041045a17a475428a26fcfb5982f.png filetype 1 errors 6, no dir index, no inode ref
>         unresolved ref dir 226516 index 9 namelen 28 name GYTSPMxjwCVp8kXB7+j91O8kcq4= filetype 1 errors 4, no inode ref
> root 9214 inode 6877070 errors 2001, no inode item, link count wrong
>         unresolved ref dir 226516 index 11 namelen 28 name VSqlYzl4pFqJpvC3GA9bQ0mZK8A= filetype 1 errors 4, no inode ref
> root 9214 inode 6878054 errors 2001, no inode item, link count wrong
>         unresolved ref dir 266982 index 22460 namelen 36 name 52e74e9d2b6f598038486f90f8f911c4.png filetype 1 errors 4, no inode ref
> root 9214 inode 6888414 errors 2001, no inode item, link count wrong
>         unresolved ref dir 226391 index 122475 namelen 14 name the-real-index filetype 1 errors 4, no inode ref
> root 9214 inode 6889202 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4096
> root 9214 inode 6889203 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4096
> ERROR: errors found in fs roots
> found 334531551237 bytes used, error(s) found
> total csum bytes: 291555464
> total tree bytes: 1004404736
> total fs tree bytes: 411713536
> total extent tree bytes: 242974720
> btree space waste bytes: 186523621
> file data blocks allocated: 36730163200
>  referenced 42646511616
> 
> 
> However, scrub and badblock find no errors.
> 
> # btrfs scrub status /mnt/
> scrub status for 7b19fb5e-4e16-4b62-b803-f59364fd61a2
>         scrub started at Tue Aug 13 07:31:38 2019 and finished after 00:02:47
>         total bytes scrubbed: 311.15GiB with 0 errors

Scrub only checks checksum, doesn't care the content.
(Kernel newer than v5.0 will care the content, but doesn't do full
cross-check, unlike btrfs-check)

> 
> # badblocks -sv /dev/kubuntu-vg/lv_root 
> Checking blocks 0 to 352133119
> Checking for bad blocks (read-only test):  done                                                 
> Pass completed, 0 bad blocks found. (0/0/0 errors)
> 
> # btrfs dev stats /dev/kubuntu-vg/lv_root                                                                                                                                                       
> [/dev/mapper/kubuntu--vg-lv_root].write_io_errs    0
> [/dev/mapper/kubuntu--vg-lv_root].read_io_errs     0
> [/dev/mapper/kubuntu--vg-lv_root].flush_io_errs    0
> [/dev/mapper/kubuntu--vg-lv_root].corruption_errs  0
> [/dev/mapper/kubuntu--vg-lv_root].generation_errs  0
> 
> 
> 
> FS mount fine, and is operational.
> would you recommend executing the btrfs check --repair option or is there something else that I can try.

Don't do anything stupid yet.
Just go LiveCD/USB and check again.

> 
> #  uname -a                                                                                                                                                                                         Linux xps 5.1.16-050116-generic #201907031232 SMP Wed Jul 3 12:35:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Since v5.2 introduced a lot of new restrict check, I'd recommend to go
mount with latest Archiso, btrfs-check first, if no problem, mount and
scrub again just in case.

> # btrfs --version                                                                                                                                                                               
> btrfs-progs v4.15.1

Big nope. You won't really want to run btrfs check --repair on such old
and buggy progs. Unless recent releases (5.2?) btrfs-progs has a bug
that transaction is not committed correctly, thus if something wrong
happened like BUG_ON() or transaction aborted, the fs can easily be
screwed up.

Thanks,
Qu

> 
> 
> mount options
> on / type btrfs (rw,relatime,compress-force=lzo,ssd,discard,space_cache=v2,autodefrag,subvol=/@)
> 
> thanks,
> Konstantin
> 


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