Errors on newly created file system

Errors on newly created file system

[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
root 5 inode 252551611 errors 2000, link count wrong
         unresolved ref dir 260775820 index 79 namelen 18 name 
generic_Apache-2.0 filetype 1 errors 0
root 5 inode 252575069 errors 2000, link count wrong
         unresolved ref dir 260777976 index 3 namelen 10 name recipeinfo 
filetype 1 errors 0
root 5 inode 252575538 errors 2000, link count wrong
         unresolved ref dir 260778506 index 3 namelen 10 name recipeinfo 
filetype 1 errors 0
root 5 inode 252577241 errors 2000, link count wrong
         unresolved ref dir 260777972 index 3 namelen 10 name recipeinfo 
filetype 1 errors 0
root 5 inode 256713617 errors 2000, link count wrong
         unresolved ref dir 260776096 index 3 namelen 12 name 
GPL-2.0-only filetype 1 errors 0
root 5 inode 256713619 errors 2000, link count wrong
         unresolved ref dir 260776096 index 5 namelen 13 name 
LGPL-2.1-only filetype 1 errors 0
root 5 inode 256713620 errors 2000, link count wrong
         unresolved ref dir 260776096 index 6 namelen 10 name recipeinfo 
filetype 1 errors 0
root 5 inode 256730804 errors 2000, link count wrong
         unresolved ref dir 260777541 index 3 namelen 7 name COPYING 
filetype 1 errors 0
         unresolved ref dir 260777543 index 3 namelen 7 name COPYING 
filetype 1 errors 0
root 5 inode 256730805 errors 2000, link count wrong
         unresolved ref dir 260777541 index 4 namelen 11 name 
COPYING.LIB filetype 1 errors 0
         unresolved ref dir 260777543 index 4 namelen 11 name 
COPYING.LIB filetype 1 errors 0
root 5 inode 256730806 errors 2000, link count wrong
         unresolved ref dir 260777541 index 5 namelen 15 name 
COPYING.RUNTIME filetype 1 errors 0
         unresolved ref dir 260777543 index 5 namelen 15 name 
COPYING.RUNTIME filetype 1 errors 0
root 5 inode 256730807 errors 2000, link count wrong
         unresolved ref dir 260777541 index 6 namelen 8 name COPYING3 
filetype 1 errors 0
         unresolved ref dir 260777543 index 6 namelen 8 name COPYING3 
filetype 1 errors 0
root 5 inode 256730808 errors 2000, link count wrong
         unresolved ref dir 260777541 index 7 namelen 12 name 
COPYING3.LIB filetype 1 errors 0
         unresolved ref dir 260777543 index 7 namelen 12 name 
COPYING3.LIB filetype 1 errors 0

...

         unresolved ref dir 260777434 index 4 namelen 10 name recipeinfo 
filetype 1 errors 0
         unresolved ref dir 260777436 index 4 namelen 10 name recipeinfo 
filetype 1 errors 0
         unresolved ref dir 260777438 index 4 namelen 10 name recipeinfo 
filetype 1 errors 0
root 5 inode 260775819 errors 2000, link count wrong
         unresolved ref dir 260775820 index 2 namelen 16 name 
license.manifest filetype 1 errors 0
ERROR: errors found in fs roots
found 1061572608 bytes used, error(s) found
total csum bytes: 990472
total tree bytes: 47329280
total fs tree bytes: 44457984
total extent tree bytes: 1511424
btree space waste bytes: 11573386
file data blocks allocated: 1014243328
  referenced 1014243328

Re: Errors on newly created file system

[Qu Wenruo]

在 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

Re: Errors on newly created file system

[Ferry Toth]

Hi,

Op 21-04-2025 om 00:00 schreef Qu Wenruo:
> 
> 
> 在 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.

Hi Qu I am confirming v6.12 resolves this issue. Afaik Yocto uses 
reflinks. I'm guessing that generates the same issue?

As a work around for people on Ubuntu Noble (20.04 LTS) with btrfs-progs 
version 6.6.3-1.1build2, installing the package from Plucky (no other 
dependencies) with version 6.12-1build1 solves this issue.

Yocto users on Scarthgap (5.0 LTS) with version 6.7.1 may copy the 
recipe meta/recipes-devtools/btrfs-tools/btrfs-tools_6.13.bb from 
walnascar or 6.14 from master. If they are building additional tools 
that use headers from this package like btrfs-compsize these may break.
> Thanks,
> Qu

Re: Errors on newly created file system

[Qu Wenruo]

在 2025/4/23 07:02, Ferry Toth 写道:
> Hi,
> 
> Op 21-04-2025 om 00:00 schreef Qu Wenruo:
>>
>>
>> 在 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.
> 
> Hi Qu I am confirming v6.12 resolves this issue. Afaik Yocto uses 
> reflinks. I'm guessing that generates the same issue?

Reflink should not cause the problem, shared extents (reflinks) are not 
longer shared inside the new btrfs.

E.g. if two inodes shares the same data extent, it will be created as 
two data extents, one for each inode.
Thus it will cause extra space usage.


It's only the hard links causing problems, as older progs directly uses 
the st_nlink reported from the host fs, but it's very possible that, 
some hard links are not inside the rootdir, thus causing missing nlinks 
inside the created btrfs.

> 
> As a work around for people on Ubuntu Noble (20.04 LTS) with btrfs-progs 
> version 6.6.3-1.1build2, installing the package from Plucky (no other 
> dependencies) with version 6.12-1build1 solves this issue.

Sorry we didn't notice the bug early enough, thus the fixes are only 
landed into v6.12, and we do not maintain backports for older progs.

Thus I'm afraid Yocto or similar projects have to require a much newer 
progs instead.

Thanks,
Qu

> 
> Yocto users on Scarthgap (5.0 LTS) with version 6.7.1 may copy the 
> recipe meta/recipes-devtools/btrfs-tools/btrfs-tools_6.13.bb from 
> walnascar or 6.14 from master. If they are building additional tools 
> that use headers from this package like btrfs-compsize these may break.
>> Thanks,
>> Qu
> 
> 

Re: Errors on newly created file system

[Ferry Toth]

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

Op woensdag 23 april 2025 00:00:36 CEST schreef Qu Wenruo:
> 
> 在 2025/4/23 07:02, Ferry Toth 写道:
> > Hi,
> > 
> > Op 21-04-2025 om 00:00 schreef Qu Wenruo:
> >>
> >>
> >> 在 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.
> > 
> > Hi Qu I am confirming v6.12 resolves this issue. Afaik Yocto uses 
> > reflinks. I'm guessing that generates the same issue?
> 
> Reflink should not cause the problem, shared extents (reflinks) are not 
> longer shared inside the new btrfs.
> 
> E.g. if two inodes shares the same data extent, it will be created as 
> two data extents, one for each inode.
> Thus it will cause extra space usage.
> 
> 
> It's only the hard links causing problems, as older progs directly uses 
> the st_nlink reported from the host fs, but it's very possible that, 
> some hard links are not inside the rootdir, thus causing missing nlinks 
> inside the created btrfs.
> 
> > 
> > As a work around for people on Ubuntu Noble (20.04 LTS) with btrfs-progs 
> > version 6.6.3-1.1build2, installing the package from Plucky (no other 
> > dependencies) with version 6.12-1build1 solves this issue.
> 
> Sorry we didn't notice the bug early enough, thus the fixes are only 
> landed into v6.12, and we do not maintain backports for older progs.

I never noticed either, while I was in a very good position to do so.

Times when I noticed filesystem errors I attributed these to unstable kernel crash. Which was probably true, never noticed errors at T0 until now.

> Thus I'm afraid Yocto or similar projects have to require a much newer 
> progs instead.

Yes that is the workaround below. You can copy the newer ”recipe” and that overrides the older one. Of course goes all the way and brings in new headers which can break dependencies (btrfs-compsize in this case).

> Thanks,
> Qu
> 
> > 
> > Yocto users on Scarthgap (5.0 LTS) with version 6.7.1 may copy the 
> > recipe meta/recipes-devtools/btrfs-tools/btrfs-tools_6.13.bb from 
> > walnascar or 6.14 from master. If they are building additional tools 
> > that use headers from this package like btrfs-compsize these may break.
> >> Thanks,
> >> Qu

While here, am I right that we can not generate the rootfs with compression on?

Reason I ask is, Yocto of course builds the rootfs and than has mkfs.btrfs create the image. But it runs as unprivileged user, so can not do mount.
And then can not do defrag.

> > 
> > 
> 
> 



[-- Attachment #1.2: Type: text/html, Size: 17587 bytes --]

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Errors on newly created file system

[Qu Wenruo]

在 2025/4/24 01:36, Ferry Toth 写道:
> Op woensdag 23 april 2025 00:00:36 CEST schreef Qu Wenruo:
> 
[...]

> 
>  > > Yocto users on Scarthgap (5.0 LTS) with version 6.7.1 may copy the
> 
>  > > recipe meta/recipes-devtools/btrfs-tools/btrfs-tools_6.13.bb from
> 
>  > > walnascar or 6.14 from master. If they are building additional tools
> 
>  > > that use headers from this package like btrfs-compsize these may break.
> 
>  > >> Thanks,
> 
>  > >> Qu
> 
> 
> While here, am I right that we can not generate the rootfs with 
> compression on?
> 
> 
> Reason I ask is, Yocto of course builds the rootfs and than has 
> mkfs.btrfs create the image. But it runs as unprivileged user, so can 
> not do mount.
> 
> And then can not do defrag.

We have this feature recently thanks to Mark!

In the latest release v6.13, there is a new option "--compress" added to 
mkfs.btrfs, which must be used with "--rootdir".

And the result is exactly what you expected, mkfs.btrfs will try to 
compress the file extents at runtime.
For uncompressible data, it will detect at the beginning and fallback to 
uncompressed data instead, exactly like the kernel.

But considering how new this feature this, it will be appreciated if 
Yocto guys can do some extra testing to make sure nothing is broken.
(Normally a btrfs check after the mkfs will be good enough)


Thanks,
Qu


> 
> 
>  > >
> 
>  > >
> 
>  >
> 
>  >
> 
> 
> 

Re: Errors on newly created file system

[Ferry Toth]

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

Op donderdag 24 april 2025 01:24:23 CEST schreef Qu Wenruo:
> 
> 在 2025/4/24 01:36, Ferry Toth 写道:
> > Op woensdag 23 april 2025 00:00:36 CEST schreef Qu Wenruo:
> > 
> [...]
> 
> > 
> >  > > Yocto users on Scarthgap (5.0 LTS) with version 6.7.1 may copy the
> > 
> >  > > recipe meta/recipes-devtools/btrfs-tools/btrfs-tools_6.13.bb from
> > 
> >  > > walnascar or 6.14 from master. If they are building additional tools
> > 
> >  > > that use headers from this package like btrfs-compsize these may break.
> > 
> >  > >> Thanks,
> > 
> >  > >> Qu
> > 
> > 
> > While here, am I right that we can not generate the rootfs with 
> > compression on?
> > 
> > 
> > Reason I ask is, Yocto of course builds the rootfs and than has 
> > mkfs.btrfs create the image. But it runs as unprivileged user, so can 
> > not do mount.
> > 
> > And then can not do defrag.
> 
> We have this feature recently thanks to Mark!
> 
> In the latest release v6.13, there is a new option "--compress" added to 
> mkfs.btrfs, which must be used with "--rootdir".
> 
> And the result is exactly what you expected, mkfs.btrfs will try to 
> compress the file extents at runtime.
> For uncompressible data, it will detect at the beginning and fallback to 
> uncompressed data instead, exactly like the kernel.

That is great, thanks!

> But considering how new this feature this, it will be appreciated if 
> Yocto guys can do some extra testing to make sure nothing is broken.
> (Normally a btrfs check after the mkfs will be good enough)
> 

I will test this.

In the meanwhile I found another problem (and I am not the first it seems see
/https://stackoverflow.com/questions/79475262/yocto-root-filesystem-ownership-issue/79590289#79590289/[1])

Yocto uses pseudo to fake root ownership. Even though the directory to be copied into the new fs is owned by an unprivileged user inside the btrfs image the files are owned by root, when created by mkfs.ext4 and mkfs.btrfs.

Except with newer mkfs.btrfs (I tested using 6.13) the files are owned by the unprivileged user. 

The result is, the image will not boot correctly.

> Thanks,
> Qu
> 
> 
> > 
> > 
> >  > >
> > 
> >  > >
> > 
> >  >
> > 
> >  >
> > 
> > 
> > 
> 
> 



--------
[1] https://stackoverflow.com/questions/79475262/yocto-root-filesystem-ownership-issue/79590289#79590289

[-- Attachment #1.2: Type: text/html, Size: 8087 bytes --]

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Errors on newly created file system

[Ferry Toth]

Hi

Op 24-04-2025 om 13:31 schreef Ferry Toth:
>
> Op donderdag 24 april 2025 01:24:23 CEST schreef Qu Wenruo:
>
> >
>
> > 在 2025/4/24 01:36, Ferry Toth 写道:
>
> > > Op woensdag 23 april 2025 00:00:36 CEST schreef Qu Wenruo:
>
> > >
>
> > [...]
>
> >
>
> > >
>
> > >  > > Yocto users on Scarthgap (5.0 LTS) with version 6.7.1 may 
> copy the
>
> > >
>
> > >  > > recipe meta/recipes-devtools/btrfs-tools/btrfs-tools_6.13.bb from
>
> > >
>
> > >  > > walnascar or 6.14 from master. If they are building 
> additional tools
>
> > >
>
> > >  > > that use headers from this package like btrfs-compsize these 
> may break.
>
> > >
>
> > >  > >> Thanks,
>
> > >
>
> > >  > >> Qu
>
> > >
>
> > >
>
> > > While here, am I right that we can not generate the rootfs with
>
> > > compression on?
>
> > >
>
> > >
>
> > > Reason I ask is, Yocto of course builds the rootfs and than has
>
> > > mkfs.btrfs create the image. But it runs as unprivileged user, so can
>
> > > not do mount.
>
> > >
>
> > > And then can not do defrag.
>
> >
>
> > We have this feature recently thanks to Mark!
>
> >
>
> > In the latest release v6.13, there is a new option "--compress" 
> added to
>
> > mkfs.btrfs, which must be used with "--rootdir".
>
> >
>
> > And the result is exactly what you expected, mkfs.btrfs will try to
>
> > compress the file extents at runtime.
>
> > For uncompressible data, it will detect at the beginning and 
> fallback to
>
> > uncompressed data instead, exactly like the kernel.
>
>
> That is great, thanks!
>
>
> > But considering how new this feature this, it will be appreciated if
>
> > Yocto guys can do some extra testing to make sure nothing is broken.
>
> > (Normally a btrfs check after the mkfs will be good enough)
>
> >
>
>
> I will test this.
>
>
> In the meanwhile I found another problem (and I am not the first it 
> seems see
>
> /https://stackoverflow.com/questions/79475262/yocto-root-filesystem-ownership-issue/79590289#79590289/ 
> <https://stackoverflow.com/questions/79475262/yocto-root-filesystem-ownership-issue/79590289#79590289>)
>
>
> Yocto uses pseudo to fake root ownership. Even though the directory to 
> be copied into the new fs is owned by an unprivileged user inside the 
> btrfs image the files are owned by root, when created by mkfs.ext4 and 
> mkfs.btrfs.
>
>
> Except with newer mkfs.btrfs (I tested using 6.13) the files are owned 
> by the unprivileged user.
>
>
> The result is, the image will not boot correctly.
>
>
I found more about this issue here

https://lore.kernel.org/yocto/tRtu.1740682678597454399.5171@lists.yoctoproject.org/T/#m5de0afa17d2c0f640e86ffe67e0d74aea467fd5b

> > Thanks,
>
> > Qu
>
> >
>
> >
>
> > >
>
> > >
>
> > >  > >
>
> > >
>
> > >  > >
>
> > >
>
> > >  >
>
> > >
>
> > >  >
>
> > >
>
> > >
>
> > >
>
> >
>
> >
>
>
>

Re: Errors on newly created file system

[Qu Wenruo]

在 2025/4/25 05:41, Ferry Toth 写道:
> Hi
> 
[...]
>>
>>
>> Except with newer mkfs.btrfs (I tested using 6.13) the files are owned 
>> by the unprivileged user.
>>
>>
>> The result is, the image will not boot correctly.
>>
>>
> I found more about this issue here
> 
> https://lore.kernel.org/yocto/ 
> tRtu.1740682678597454399.5171@lists.yoctoproject.org/T/ 
> #m5de0afa17d2c0f640e86ffe67e0d74aea467fd5b
> 
Thanks for the report.

Just want to be sure, with pseudo emulating root environment, how does 
it handle the file uid/gid?

Mkfs.btrfs uses the uid/gid reported from stat() system calls, thus if 
pseudo doesn't change uid/gid reported from stat(), mkfs.btrfs will just 
follow the result.

I guess it's possible for us to implement an idmap-like solution, but 
I'd like to know how pseudo works first.

Thanks,
Qu

Re: Errors on newly created file system

[Ferry Toth]

Op 24-04-2025 om 22:49 schreef Qu Wenruo:
> 
> 
> 在 2025/4/25 05:41, Ferry Toth 写道:
>> Hi
>>
> [...]
>>>
>>>
>>> Except with newer mkfs.btrfs (I tested using 6.13) the files are 
>>> owned by the unprivileged user.
>>>
>>>
>>> The result is, the image will not boot correctly.
>>>
>>>
>> I found more about this issue here
>>
>> https://lore.kernel.org/yocto/ 
>> tRtu.1740682678597454399.5171@lists.yoctoproject.org/T/ 
>> #m5de0afa17d2c0f640e86ffe67e0d74aea467fd5b
>>
> Thanks for the report.
> 
> Just want to be sure, with pseudo emulating root environment, how does 
> it handle the file uid/gid?
> 
> Mkfs.btrfs uses the uid/gid reported from stat() system calls, thus if 
> pseudo doesn't change uid/gid reported from stat(), mkfs.btrfs will just 
> follow the result.

The change in mkfs.btrfs is reportedly:
"The important change is that previously mkfs.btrfs was
using lstat syscall to get file stats, but then it switched to nftw libc
function to do the same. Pseudo[3] however doesn't support this call -
it "knows" that it exists (at least nftw64), but there seems to be no
implementation."

So, as I understand, pseudo would hook into stats call, lookup in 
database and change uid/gid accordingly. But now there is only a stub.

Right now I am trying a patch for pseudo that implements nftw64. It 
triggers a rebuild for half my image, so that will takes another hour or 
so. I'll let you know how that goes.

This particular problem does seem to be more pseudo related.

> I guess it's possible for us to implement an idmap-like solution, but 
> I'd like to know how pseudo works first.
> 
> Thanks,
> Qu

Re: Errors on newly created file system

[Ferry Toth]

Op 24-04-2025 om 01:24 schreef Qu Wenruo:
> 在 2025/4/24 01:36, Ferry Toth 写道:
>> Op woensdag 23 april 2025 00:00:36 CEST schreef Qu Wenruo:

>> While here, am I right that we can not generate the rootfs with 
>> compression on?
>>
>>
>> Reason I ask is, Yocto of course builds the rootfs and than has 
>> mkfs.btrfs create the image. But it runs as unprivileged user, so can 
>> not do mount.
>>
>> And then can not do defrag.
> 
> We have this feature recently thanks to Mark!
> 
> In the latest release v6.13, there is a new option "--compress" added to 
> mkfs.btrfs, which must be used with "--rootdir".

I built 6.14 while configuring with --enable-lzo

Configure says:
	zstd support:       no
	lzo support:        yes

Finally running mkfs.btrfs with --compress lzo

I get:
-EXPERIMENTAL -INJECT -STATIC -LZO -ZSTD -UDEV +FSVERITY -ZONED 
CRYPTO=builtin

And
ERROR: lzo support not compiled in

Strangely: when I run with --compress zlib and I check the resulting 
image with btrfs-compsize it says:

Processed 8969984 files, 2574779 regular extents (6008702 refs), 5007593 
inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       91%      532G         582G         820G
none       100%      489G         489G         575G
zlib        38%      350M         902M         926M
lzo         46%       42G          92G         243G
prealloc   100%       99M          99M         678M

Seems like it tries lzo anyway and is mixed up about support not built in.

Re: Errors on newly created file system

[Ferry Toth]

Hi

Op 24-04-2025 om 23:16 schreef Ferry Toth:
> Op 24-04-2025 om 22:49 schreef Qu Wenruo:
>>
>>
>> 在 2025/4/25 05:41, Ferry Toth 写道:
>>> Hi
>>>
>> [...]
>>>>
>>>>
>>>> Except with newer mkfs.btrfs (I tested using 6.13) the files are 
>>>> owned by the unprivileged user.
>>>>
>>>>
>>>> The result is, the image will not boot correctly.
>>>>
>>>>
>>> I found more about this issue here
>>>
>>> https://lore.kernel.org/yocto/ 
>>> tRtu.1740682678597454399.5171@lists.yoctoproject.org/T/ 
>>> #m5de0afa17d2c0f640e86ffe67e0d74aea467fd5b
>>>
>> Thanks for the report.
>>
>> Just want to be sure, with pseudo emulating root environment, how does 
>> it handle the file uid/gid?
>>
>> Mkfs.btrfs uses the uid/gid reported from stat() system calls, thus if 
>> pseudo doesn't change uid/gid reported from stat(), mkfs.btrfs will 
>> just follow the result.
> 
> The change in mkfs.btrfs is reportedly:
> "The important change is that previously mkfs.btrfs was
> using lstat syscall to get file stats, but then it switched to nftw libc
> function to do the same. Pseudo[3] however doesn't support this call -
> it "knows" that it exists (at least nftw64), but there seems to be no
> implementation."
> 
> So, as I understand, pseudo would hook into stats call, lookup in 
> database and change uid/gid accordingly. But now there is only a stub.
> 
> Right now I am trying a patch for pseudo that implements nftw64. It 
> triggers a rebuild for half my image, so that will takes another hour or 
> so. I'll let you know how that goes.
> 
> This particular problem does seem to be more pseudo related.

Yes, the patch for pseudo is working. So, this is not a mkfs.btrfs bug.

Thanks for your support!

>> I guess it's possible for us to implement an idmap-like solution, but 
>> I'd like to know how pseudo works first.
>>
>> Thanks,
>> Qu
>