All of lore.kernel.org
 help / color / mirror / Atom feed
From: Saul Wold <sgw@linux.intel.com>
To: "quwenruo@cn.fujitsu.com" <quwenruo@cn.fujitsu.com>,
	Zach Brown <zab@zabbo.net>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	"dg77.kim@samsung.com" <dg77.kim@samsung.com>
Subject: Re: Building a brtfs filesystem < 70M?
Date: Tue, 11 Mar 2014 18:43:25 -0700	[thread overview]
Message-ID: <531FBBBD.9000109@linux.intel.com> (raw)
In-Reply-To: <531FB42C.5000101@cn.fujitsu.com>

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
>

      reply	other threads:[~2014-03-12  1:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-10 23:25 Building a brtfs filesystem < 70M? Saul Wold
2014-03-11  0:16 ` cwillu
2014-03-11  2:38 ` Gui Hecheng
2014-03-11  3:16   ` Saul Wold
2014-03-11  5:47     ` Gui Hecheng
2014-03-11  6:41       ` Saul Wold
2014-03-11  7:51         ` Gui Hecheng
2014-03-11 16:37 ` Zach Brown
2014-03-12  1:10   ` quwenruo
2014-03-12  1:43     ` Saul Wold [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=531FBBBD.9000109@linux.intel.com \
    --to=sgw@linux.intel.com \
    --cc=dg77.kim@samsung.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo@cn.fujitsu.com \
    --cc=zab@zabbo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.