Building a brtfs filesystem < 70M?

DISCUSSION Saul Wold 5 participants 10 messages Mar 10, 2014 – Mar 12, 2014 Btrfs file system

Share & tools

Saul Wold

author

2014-03-10 23:25 UTC #0 lore raw

Hi There

There seems to be an issue if we try to build a btrfs based FS that is less than 70M, we get the following assertion failure:

mkfs.btrfs: extent-tree.c:2682: btrfs_reserve_extent: Assertion `!(ret)' failed.

I tried to do a search on this and did not find anything obvious.

Further, if I do build a 70M image, it will not mount until I get to I increase the about 100M!

# mount -o loop -v rootfs.btrfs mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error

In some cases useful info is found in syslog - try dmesg | tail or so.

I can provide a small rootfs (~4M) example if needed

Builds and mounts correct:
mkfs.btrfs -b 104857600 -r rootfs rootfs.btrfs

Builds, but does not mount:
mkfs.btrfs -b 73400320 -r rootfs rootfs.btrfs

Does not build, gives the above assertion error:
mkfs.btrfs -b 10889216 -r rootfs rootfs.btrfs

Thanks

Signature · 5 lines

    Sau!

Saul Wold
Yocto Component Wrangler @ Intel
Yocto Project / Poky Build System

cwillu

2014-03-11 00:16 UTC #1 lore raw

Have you tried the -M option to mkfs.btrfs? I'm not sure if we select it automatically (or if we do, whether you have recent enough tools to have that).

Gui Hecheng

2014-03-11 03:00 UTC #2 lore raw

In reply to Saul Wold

Quoted 25 lines · Saul Wold

Hi There
There seems to be an issue if we try to build a btrfs based FS that is less than 70M, we get the following assertion failure:
mkfs.btrfs: extent-tree.c:2682: btrfs_reserve_extent: Assertion `!(ret)' failed.
I tried to do a search on this and did not find anything obvious.
Further, if I do build a 70M image, it will not mount until I get to I increase the about 100M!
# mount -o loop -v rootfs.btrfs mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
        missing codepage or helper program, or other error
In some cases useful info is found in syslog - try dmesg | tail or so.
I can provide a small rootfs (~4M) example if needed
Builds and mounts correct:
mkfs.btrfs -b 104857600 -r rootfs rootfs.btrfs

Quoted 9 lines

Builds, but does not mount:
mkfs.btrfs -b 73400320 -r rootfs rootfs.btrfs
Does not build, gives the above assertion error:
mkfs.btrfs -b 10889216 -r rootfs rootfs.btrfs
Thanks

Hi Saul,
Sorry, I'm not able to reproduce your problem... Are you running the latest btrfs-progs from david's branch?

Thanks,
Gui

Saul Wold

author

2014-03-11 03:16 UTC #3 lore raw

Quoted 33 lines · Gui Hecheng

Quoted 32 lines · Saul Wold
Hi There
There seems to be an issue if we try to build a btrfs based FS that is less than 70M, we get the following assertion failure:
mkfs.btrfs: extent-tree.c:2682: btrfs_reserve_extent: Assertion `!(ret)' failed.
I tried to do a search on this and did not find anything obvious.
Further, if I do build a 70M image, it will not mount until I get to I increase the about 100M!
# mount -o loop -v rootfs.btrfs mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
         missing codepage or helper program, or other error
In some cases useful info is found in syslog - try dmesg | tail or so.
I can provide a small rootfs (~4M) example if needed
Builds and mounts correct:
mkfs.btrfs -b 104857600 -r rootfs rootfs.btrfs
Builds, but does not mount:
mkfs.btrfs -b 73400320 -r rootfs rootfs.btrfs
Does not build, gives the above assertion error:
mkfs.btrfs -b 10889216 -r rootfs rootfs.btrfs

Quoted 6 lines

Quoted 2 lines
Thanks
Hi Saul,
Sorry, I'm not able to reproduce your problem... Are you running the latest btrfs-progs from david's branch?

Yes, I am building it from git using master I think, git hash: 8cae1840afb3ea44dcc298f32983e577480dfee4

I tried both with and without the -M as cwillu suggested, still no joy, I can send some the rootfs I am using to see if is's something specific.

Here's the full failure:

$ tmp/sysroots/x86_64-linux/usr/bin/mkfs.btrfs -M -b 10889216 -r tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs rootfs.btrfs
SMALL VOLUME: forcing mixed metadata/data groups
SMALL VOLUME: forcing mixed metadata/data groups

WARNING! - Btrfs v3.12-dirty IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using

Turning ON incompat feature 'mixed-bg': mixed data and metadata block groups Turning ON incompat feature 'extref': increased hardlink limit per file to 65536 Created a data/metadata chunk of size 8388608
fs created label (null) on rootfs.btrfs

	nodesize 4096 leafsize 4096 sectorsize 4096 size 180.00MiB

Btrfs v3.12-dirty
scandir for tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs failed: No such file or directory unable to traverse_directory
Making image is aborted.
mkfs.btrfs: mkfs.c:1592: main: Assertion `!(ret)' failed.
Aborted (core dumped)

Thanks for the help!

Sau!

Quoted 4 lines

Thanks,
Gui

Gui Hecheng

2014-03-11 05:51 UTC #4 lore raw

Quoted 72 lines · Saul Wold

Quoted 33 lines · Gui Hecheng
Quoted 32 lines · Saul Wold
Hi There
There seems to be an issue if we try to build a btrfs based FS that is less than 70M, we get the following assertion failure:
mkfs.btrfs: extent-tree.c:2682: btrfs_reserve_extent: Assertion `!(ret)' failed.
I tried to do a search on this and did not find anything obvious.
Further, if I do build a 70M image, it will not mount until I get to I increase the about 100M!
# mount -o loop -v rootfs.btrfs mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
         missing codepage or helper program, or other error
In some cases useful info is found in syslog - try dmesg | tail or so.
I can provide a small rootfs (~4M) example if needed
Builds and mounts correct:
mkfs.btrfs -b 104857600 -r rootfs rootfs.btrfs
Builds, but does not mount:
mkfs.btrfs -b 73400320 -r rootfs rootfs.btrfs
Does not build, gives the above assertion error:
mkfs.btrfs -b 10889216 -r rootfs rootfs.btrfs
Quoted 6 lines
Quoted 2 lines
Thanks
Hi Saul,
Sorry, I'm not able to reproduce your problem... Are you running the latest btrfs-progs from david's branch?
Yes, I am building it from git using master I think, git hash:
8cae1840afb3ea44dcc298f32983e577480dfee4
I tried both with and without the -M as cwillu suggested, still no joy, I can send some the rootfs I am using to see if is's something specific.
Here's the full failure:
$ tmp/sysroots/x86_64-linux/usr/bin/mkfs.btrfs -M -b 10889216 -r 
tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs rootfs.btrfs
SMALL VOLUME: forcing mixed metadata/data groups
SMALL VOLUME: forcing mixed metadata/data groups
WARNING! - Btrfs v3.12-dirty IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using
Turning ON incompat feature 'mixed-bg': mixed data and metadata block groups Turning ON incompat feature 'extref': increased hardlink limit per file to 65536
Created a data/metadata chunk of size 8388608
fs created label (null) on rootfs.btrfs
	nodesize 4096 leafsize 4096 sectorsize 4096 size 180.00MiB
Btrfs v3.12-dirty
scandir for tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs failed:
No such file or directory
unable to traverse_directory
Making image is aborted.
mkfs.btrfs: mkfs.c:1592: main: Assertion `!(ret)' failed. Aborted (core dumped)

Quoted 4 lines

Thanks for the help!
Sau!

I think the output really tells us the problem: the mkfs '-r' option requires a 'directory' as an arg.
But still it should not abort with 'core dumped', I would be glad to make it more friendly.

-Gui

Quoted 5 lines

Quoted 5 lines
Thanks,
Gui

Saul Wold

author

2014-03-11 06:41 UTC #5 lore raw

Quoted 73 lines · Gui Hecheng

Quoted 72 lines · Saul Wold
Quoted 33 lines · Gui Hecheng
Quoted 32 lines · Saul Wold
Hi There
There seems to be an issue if we try to build a btrfs based FS that is less than 70M, we get the following assertion failure:
mkfs.btrfs: extent-tree.c:2682: btrfs_reserve_extent: Assertion `!(ret)' failed.
I tried to do a search on this and did not find anything obvious.
Further, if I do build a 70M image, it will not mount until I get to I increase the about 100M!
# mount -o loop -v rootfs.btrfs mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
          missing codepage or helper program, or other error
In some cases useful info is found in syslog - try dmesg | tail or so.
I can provide a small rootfs (~4M) example if needed
Builds and mounts correct:
mkfs.btrfs -b 104857600 -r rootfs rootfs.btrfs
Builds, but does not mount:
mkfs.btrfs -b 73400320 -r rootfs rootfs.btrfs
Does not build, gives the above assertion error:
mkfs.btrfs -b 10889216 -r rootfs rootfs.btrfs
Quoted 6 lines
Quoted 2 lines
Thanks
Hi Saul,
Sorry, I'm not able to reproduce your problem... Are you running the latest btrfs-progs from david's branch?
Yes, I am building it from git using master I think, git hash:
8cae1840afb3ea44dcc298f32983e577480dfee4
I tried both with and without the -M as cwillu suggested, still no joy, I can send some the rootfs I am using to see if is's something specific.
Here's the full failure:
$ tmp/sysroots/x86_64-linux/usr/bin/mkfs.btrfs -M -b 10889216 -r
tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs rootfs.btrfs
SMALL VOLUME: forcing mixed metadata/data groups
SMALL VOLUME: forcing mixed metadata/data groups
WARNING! - Btrfs v3.12-dirty IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using
Turning ON incompat feature 'mixed-bg': mixed data and metadata block groups Turning ON incompat feature 'extref': increased hardlink limit per file to 65536
Created a data/metadata chunk of size 8388608
fs created label (null) on rootfs.btrfs
	nodesize 4096 leafsize 4096 sectorsize 4096 size 180.00MiB
Btrfs v3.12-dirty
scandir for tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs failed:
No such file or directory
unable to traverse_directory
Making image is aborted.
mkfs.btrfs: mkfs.c:1592: main: Assertion `!(ret)' failed. Aborted (core dumped)

Quoted 9 lines

Quoted 4 lines
Thanks for the help!
Sau!
I think the output really tells us the problem: the mkfs '-r' option requires a 'directory' as an arg.
But still it should not abort with 'core dumped', I would be glad to make it more friendly.

Yes, the "tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs" is a directory containing a rootfs, we use this with genext2fs with no issues. As I said, I can provide you with a tarball of this directory if you wish to try and reproduce this issue.

Sau!

Quoted 8 lines

-Gui
Quoted 5 lines
Quoted 5 lines
Thanks,
Gui

Gui Hecheng

2014-03-11 07:55 UTC #6 lore raw

Quoted 83 lines · Saul Wold

Quoted 73 lines · Gui Hecheng
Quoted 72 lines · Saul Wold
Quoted 33 lines · Gui Hecheng
Quoted 32 lines · Saul Wold
Hi There
There seems to be an issue if we try to build a btrfs based FS that is less than 70M, we get the following assertion failure:
mkfs.btrfs: extent-tree.c:2682: btrfs_reserve_extent: Assertion `!(ret)' failed.
I tried to do a search on this and did not find anything obvious.
Further, if I do build a 70M image, it will not mount until I get to I increase the about 100M!
# mount -o loop -v rootfs.btrfs mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
          missing codepage or helper program, or other error
In some cases useful info is found in syslog - try dmesg | tail or so.
I can provide a small rootfs (~4M) example if needed
Builds and mounts correct:
mkfs.btrfs -b 104857600 -r rootfs rootfs.btrfs
Builds, but does not mount:
mkfs.btrfs -b 73400320 -r rootfs rootfs.btrfs
Does not build, gives the above assertion error:
mkfs.btrfs -b 10889216 -r rootfs rootfs.btrfs
Quoted 6 lines
Quoted 2 lines
Thanks
Hi Saul,
Sorry, I'm not able to reproduce your problem... Are you running the latest btrfs-progs from david's branch?
Yes, I am building it from git using master I think, git hash:
8cae1840afb3ea44dcc298f32983e577480dfee4
I tried both with and without the -M as cwillu suggested, still no joy, I can send some the rootfs I am using to see if is's something specific.
Here's the full failure:
$ tmp/sysroots/x86_64-linux/usr/bin/mkfs.btrfs -M -b 10889216 -r
tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs rootfs.btrfs
SMALL VOLUME: forcing mixed metadata/data groups
SMALL VOLUME: forcing mixed metadata/data groups
WARNING! - Btrfs v3.12-dirty IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using
Turning ON incompat feature 'mixed-bg': mixed data and metadata block groups Turning ON incompat feature 'extref': increased hardlink limit per file to 65536
Created a data/metadata chunk of size 8388608
fs created label (null) on rootfs.btrfs
	nodesize 4096 leafsize 4096 sectorsize 4096 size 180.00MiB
Btrfs v3.12-dirty
scandir for tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs failed:
No such file or directory
unable to traverse_directory
Making image is aborted.
mkfs.btrfs: mkfs.c:1592: main: Assertion `!(ret)' failed. Aborted (core dumped)
Quoted 9 lines
Quoted 4 lines
Thanks for the help!
Sau!
I think the output really tells us the problem: the mkfs '-r' option requires a 'directory' as an arg.
But still it should not abort with 'core dumped', I would be glad to make it more friendly.

Quoted 8 lines

Yes, the "tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs" is a directory containing a rootfs, we use this with genext2fs with no issues. As I said, I can provide you with a tarball of this directory if you wish to try and reproduce this issue.
Sau!

Acturally, I notised that u'v present 2 different BUG_ON()
1. extent-tree.c:2682:btrfs_reserve_extent
2. mkfs.c:1592:main

The 'full failure' u showed is for the 2nd, not the 1st.

o For the 1st, it is really a space related thing.
o For the 2nd, the 'errno' of the scandir() won't lie, please check whether arg for '-r' is 'valid'.

For the ~4M rootfs... I will be glad for your kind offer~ Please send it to me.

-Gui

Quoted 8 lines

Quoted 8 lines
-Gui
Quoted 5 lines
Quoted 5 lines
Thanks,
Gui

Zach Brown

2014-03-11 16:42 UTC #7 lore raw

In reply to Saul Wold

Quoted 7 lines

There seems to be an issue if we try to build a btrfs based FS that is less than 70M, we get the following assertion failure:
mkfs.btrfs: extent-tree.c:2682: btrfs_reserve_extent: Assertion `!(ret)' failed.
mkfs.btrfs -b 104857600 -r rootfs rootfs.btrfs

Honestly, the path of least resistance is probably to avoid the -r option all together. As you've found, it's not reliable.

I'd take the time to roll the infrastrcture to populate the image by writing to a mounted image with the kernel code.

- z

[email protected]

2014-03-12 01:10 UTC #8 lore raw

Quoted 9 lines · Zach Brown

Quoted 6 lines
There seems to be an issue if we try to build a btrfs based FS that is less than 70M, we get the following assertion failure:
mkfs.btrfs: extent-tree.c:2682: btrfs_reserve_extent: Assertion `!(ret)' failed.
mkfs.btrfs -b 104857600 -r rootfs rootfs.btrfs
Honestly, the path of least resistance is probably to avoid the -r option all together. As you've found, it's not reliable.

Quoted 9 lines

I'd take the time to roll the infrastrcture to populate the image by writing to a mounted image with the kernel code.
- z
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

I although agree with the mount + cp(kernel) way to populate the filesystem. Also I think the implement of "-r" should be somewhat like mount+cp other than the current way,
since the userland implement is noticeably slow than kernel way.

Cc:Donggeun Kim
I also wonder why "-r" option is needed, since IMO the "-r" options is only needed
if the filesystem is full readonly and must be populated on initialization like squashfs.
And since btrfs is a filesystem that can be read and write, the "-r" option is not somewhat needed.

So I prefer to remove the "-r" option.

Thanks Qu��{.n�+��+%��ݶ��w��{.n�+��{��k~��^n�r��z��h��&��z��z�ޗ�+��+zf��h��~��i��z_��j:+v��)ߣ�m

Saul Wold

author

2014-03-12 01:43 UTC #9 lore raw

Quoted 32 lines · On 03/11/2014 06:10 PM, [email protected] wrote:

Quoted 9 lines · Zach Brown
Quoted 6 lines
There seems to be an issue if we try to build a btrfs based FS that is less than 70M, we get the following assertion failure:
mkfs.btrfs: extent-tree.c:2682: btrfs_reserve_extent: Assertion `!(ret)' failed.
mkfs.btrfs -b 104857600 -r rootfs rootfs.btrfs
Honestly, the path of least resistance is probably to avoid the -r option all together. As you've found, it's not reliable.
Quoted 9 lines
I'd take the time to roll the infrastrcture to populate the image by writing to a mounted image with the kernel code.
- z
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
I although agree with the mount + cp(kernel) way to populate the filesystem. Also I think the implement of "-r" should be somewhat like mount+cp other than the current way,
since the userland implement is noticeably slow than kernel way.
Cc:Donggeun Kim
I also wonder why "-r" option is needed, since IMO the "-r" options is only needed
if the filesystem is full readonly and must be populated on initialization like squashfs.
And since btrfs is a filesystem that can be read and write, the "-r" option is not somewhat needed.

Quoted 2 lines

So I prefer to remove the "-r" option.

Please dont remove the -r option, as you point out above it's used from userland. The Yocto Project / OE-Core uses this option to build a put a rootfs into a filesystem image in userland without requiring root permissions, we use something call pseudo (it a smarter version of fakeroot) to lay down a root filesytem.

The patch from Gui worked well for our purposes, we are no longer failing to build the filesystem image.

Thanks

Sau!

Quoted 4 lines

Thanks
Qu