Re: Errors on newly created file system

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

在 2025/4/21 07:15, Ferry Toth 写道:
> The following is originally done by Yocto's bitbake, but when I try 
> manually it reproduces.
> 
> I create a new fs on  a file using -r as ordinary user, then btrfs check 
> the file (before or after mounting makes no difference), also as an 
> ordinary user.
> 
> The fs has 1000's of errors, I cut most because it seems the same type 
> of errors. The files system is unrepaired bootable, but can be repaired 
> using --repair, in which 1000's of files are moved to lost+found.
> 
> The below was mkfs on a non-existing file, but writing to 16GB dduped 
> file (rootfs is 1.4GB) makes no difference. Neither does dropping -- 
> shrink, -m or -n.
> 
> Also, writing the file to an actual disk and then check the disk gives 
> the same errors.
> 
> What could this be?
> 
> ferry@delfion:~/tmp/edison/edison-scarthgap$ mkfs.btrfs -n 4096 --shrink 
> -M -v -r /home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/build/ 
> tmp/work/edison-poky-linux/edison-image/1.0/rootfs edison-image- 
> edison.rootfs.btrfs
> btrfs-progs v6.6.3
> See https://btrfs.readthedocs.io for more information.
> 
> ERROR: zoned: unable to stat edison-image-edison.rootfs.btrfs
> NOTE: several default settings have changed in version 5.15, please make 
> sure
>        this does not affect your deployments:
>        - DUP for metadata (-m dup)
>        - enabled no-holes (-O no-holes)
>        - enabled free-space-tree (-R free-space-tree)
> 
> Rootdir from: /home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/ 
> build/tmp/work/edison-poky-linux/edison-image/1.0/rootfs
>    Shrink:           yes
> Label:              (null)
> UUID:               c2ecfaca-168a-401b-a12a-e73694d7485a
> Node size:          4096
> Sector size:        4096
> Filesystem size:    1.43GiB
> Block group profiles:
>    Data+Metadata:    single            1.42GiB
>    System:           single            4.00MiB
> SSD detected:       no
> Zoned device:       no
> Incompat features:  mixed-bg, extref, skinny-metadata, no-holes, free- 
> space-tree
> Runtime features:   free-space-tree
> Checksum:           crc32c
> Number of devices:  1
> Devices:
>     ID        SIZE  PATH
>      1     1.43GiB  edison-image-edison.rootfs.btrfs
> 
> ferry@delfion:~/tmp/edison/edison-scarthgap$ btrfs check edison-image- 
> edison.rootfs.btrfs
> Opening filesystem to check...
> Checking filesystem on edison-image-edison.rootfs.btrfs
> UUID: c2ecfaca-168a-401b-a12a-e73694d7485a
> [1/7] checking root items
> [2/7] checking extents
> [3/7] checking free space tree
> [4/7] checking fs roots
> root 5 inode 252551099 errors 2000, link count wrong
>          unresolved ref dir 260778488 index 2 namelen 11 name 
> COPYING.MIT filetype 1 errors 0

Looks like exactly the nlink bugs related to --rootdir option.

And that's fixed in v6.10 first, by the commit c6464d3f99ed 
("btrfs-progs: mkfs: rework how we traverse rootdir"), then further 
improved in v6.12 with the commit ef1157473372 ("btrfs-progs: mkfs: add 
hard link support for --rootdir").


So in short, if the directory contains hardlinks out of the directory, 
then you have to use btrfs-progs newer than v6.12.

Thanks,
Qu