Building a brtfs filesystem < 70M?

Building a brtfs filesystem < 70M?

[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


Thanks


-- 
     Sau!

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

Re: Building a brtfs filesystem < 70M?

[cwillu]

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).

Re: Building a brtfs filesystem < 70M?

[Gui Hecheng]

On Mon, 2014-03-10 at 16:25 -0700, Saul Wold wrote:
> 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
> 
Hi Saul,
Sorry, I'm not able to reproduce your problem...
Are you running the latest btrfs-progs from david's branch?

Thanks,
Gui

Re: Building a brtfs filesystem < 70M?

[Saul Wold]

On 03/10/2014 07:38 PM, Gui Hecheng wrote:
> On Mon, 2014-03-10 at 16:25 -0700, Saul Wold wrote:
>> 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
>>
> 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!



> Thanks,
> Gui
>
>

Re: Building a brtfs filesystem < 70M?

[Gui Hecheng]

On Mon, 2014-03-10 at 20:16 -0700, Saul Wold wrote:
> On 03/10/2014 07:38 PM, Gui Hecheng wrote:
> > On Mon, 2014-03-10 at 16:25 -0700, Saul Wold wrote:
> >> 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
> >>
> > 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!
> 
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
> 
> > Thanks,
> > Gui
> >
> >

Re: Building a brtfs filesystem < 70M?

[Saul Wold]

On 03/10/2014 10:47 PM, Gui Hecheng wrote:
> On Mon, 2014-03-10 at 20:16 -0700, Saul Wold wrote:
>> On 03/10/2014 07:38 PM, Gui Hecheng wrote:
>>> On Mon, 2014-03-10 at 16:25 -0700, Saul Wold wrote:
>>>> 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
>>>>
>>> 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!
>>
> 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!

> -Gui
>>
>>> Thanks,
>>> Gui
>>>
>>>
>
>

Re: Building a brtfs filesystem < 70M?

[Gui Hecheng]

On Mon, 2014-03-10 at 23:41 -0700, Saul Wold wrote:
> On 03/10/2014 10:47 PM, Gui Hecheng wrote:
> > On Mon, 2014-03-10 at 20:16 -0700, Saul Wold wrote:
> >> On 03/10/2014 07:38 PM, Gui Hecheng wrote:
> >>> On Mon, 2014-03-10 at 16:25 -0700, Saul Wold wrote:
> >>>> 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
> >>>>
> >>> 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!
> >>
> > 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!
> 
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

> > -Gui
> >>
> >>> Thanks,
> >>> Gui
> >>>
> >>>
> >
> >

Re: Building a brtfs filesystem < 70M?

[Zach Brown]

> 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

Re: Building a brtfs filesystem < 70M?

[quwenruo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1501 bytes --]

On Tue, 11 Mar 2014 09:37:00 -0700, Zach Brown wrote:
>> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> 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Ç+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ý»k~ÏâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm

Re: Building a brtfs filesystem < 70M?

[Saul Wold]

On 03/11/2014 06:10 PM, quwenruo@cn.fujitsu.com wrote:
> On Tue, 11 Mar 2014 09:37:00 -0700, Zach Brown wrote:
>>> 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
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> 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.
>
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!

>
> Thanks
> Qu
>