Btrfs devel - Dec 2008 - [PATCH] Btrfs-progs: btrfs file system size should be bigger then 256m

According to btrfs_prepare_device, btrfs file sysstem size
should be bigger then 256m.

If mkfs.btrfs specifies the file system size samaller then
that, mkfs.btrfs should report error.

Signed-off-by: Shen Feng <shen@cn.fujitsu.com>
---
 mkfs.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/mkfs.c b/mkfs.c
index be93aaa..447e8d7 100644
--- a/mkfs.c
+++ b/mkfs.c
@@ -377,6 +377,10 @@ int main(int ac, char **av)
 				break;
 			case ''b'':
 				block_count = parse_size(optarg);
+				if (block_count < 256*1024*1024) {
+					fprintf(stderr, "File system size is too small\n");
+					exit(1);
+				}
 				zero_end = 0;
 				break;
 			default:
-- 
1.6.0.6
--
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

This has been bothering me for some time. Why does btrfs need to have a 
disk greater then 256M? I could see a much smaller limit, say 16M but 
why so much? The file system itself does not need that much space for 
its own use.

Thanks,

Lee

Shen Feng wrote:
> According to btrfs_prepare_device, btrfs file sysstem size
> should be bigger then 256m.
>
> If mkfs.btrfs specifies the file system size samaller then
> that, mkfs.btrfs should report error.
>
> Signed-off-by: Shen Feng <shen@cn.fujitsu.com>
> ---
>  mkfs.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/mkfs.c b/mkfs.c
> index be93aaa..447e8d7 100644
> --- a/mkfs.c
> +++ b/mkfs.c
> @@ -377,6 +377,10 @@ int main(int ac, char **av)
>  				break;
>  			case ''b'':
>  				block_count = parse_size(optarg);
> +				if (block_count < 256*1024*1024) {
> +					fprintf(stderr, "File system size is too small\n");
> +					exit(1);
> +				}
>  				zero_end = 0;
>  				break;
>  			default:
>   
--
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

My test shows that at least 100M is needed for a btrfs partition.

on 12/31/2008 03:41 PM, Lee Trager wrote:
> This has been bothering me for some time. Why does btrfs need to have a
> disk greater then 256M? I could see a much smaller limit, say 16M but
> why so much? The file system itself does not need that much space for
> its own use.
> 
> Thanks,
> 
> Lee
> 
> Shen Feng wrote:
>> According to btrfs_prepare_device, btrfs file sysstem size
>> should be bigger then 256m.
>>
>> If mkfs.btrfs specifies the file system size samaller then
>> that, mkfs.btrfs should report error.
>>
>> Signed-off-by: Shen Feng <shen@cn.fujitsu.com>
>> ---
>>  mkfs.c |    4 ++++
>>  1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/mkfs.c b/mkfs.c
>> index be93aaa..447e8d7 100644
>> --- a/mkfs.c
>> +++ b/mkfs.c
>> @@ -377,6 +377,10 @@ int main(int ac, char **av)
>>                  break;
>>              case ''b'':
>>                  block_count = parse_size(optarg);
>> +                if (block_count < 256*1024*1024) {
>> +                    fprintf(stderr, "File system size is too
small\n");
>> +                    exit(1);
>> +                }
>>                  zero_end = 0;
>>                  break;
>>              default:
>>   
> 
> -- 
> 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
> 
> 
-- 
Best Regards,
--------------------------------------------------
Shen Feng
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
8/F., Civil Defense Building, No.189 Guangzhou Road,
Nanjing, 210029, China
PHONE: +86-25-86630566-950
COINS: 79955-950
FAX: +86-25-83317685
MAIL: shen@cn.fujitsu.com
-------------------------------------------------
This communication is for use by the intended recipient(s) only and may contain
information that is privileged, confidential and exempt from disclosure under
applicable law. If you are not an intended recipient of this communication, you
are hereby notified that any dissemination, distribution or copying hereof is
strictly prohibited.  If you have received this communication in error, please
notify me by reply e-mail, permanently delete this communication from your
system, and destroy any hard copies you may have printed.
--
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

> +				if (block_count < 256*1024*1024) {
> +					fprintf(stderr, "File system size is too small\n");
> +					exit(1);
> +				}
And please, if you could, include both the size that is too small and
the size that is required in the message.

- 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

on 01/01/2009 01:49 AM, Zach Brown wrote:
>> +				if (block_count < 256*1024*1024) {
>> +					fprintf(stderr, "File system size is too small\n");
>> +					exit(1);
>> +				}
> 
> And please, if you could, include both the size that is too small and
> the size that is required in the message.
> 
Thanks. I updated the patch.

Signed-off-by: Shen Feng <shen@cn.fujitsu.com>
---
 mkfs.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/mkfs.c b/mkfs.c
index be93aaa..cb21db6 100644
--- a/mkfs.c
+++ b/mkfs.c
@@ -377,6 +377,13 @@ int main(int ac, char **av)
 				break;
 			case ''b'':
 				block_count = parse_size(optarg);
+				if (block_count < 256*1024*1024) {
+					fprintf(stderr, "File system size "
+						"%llu bytes is too small, "
+						"256M is required at least\n",
+						block_count);
+					exit(1);
+				}
 				zero_end = 0;
 				break;
 			default:
--
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

> This has been bothering me for some time. Why does btrfs need to have a 
> disk greater then 256M? I could see a much smaller limit, say 16M but 
> why so much? The file system itself does not need that much space for 
> its own use.
In other words, 256M limit rather disqualifies btrfs as a filesystem 
i.e. for /boot, doesn''t it?


-- 
Tomasz Chmielewski
http://wpkg.org

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

Kaspar Schleiser schrieb:
> Hey,
> 
> Tomasz Chmielewski wrote:
>>> This has been bothering me for some time. Why does btrfs need to
have
>>> a disk greater then 256M? I could see a much smaller limit, say 16M
>>> but why so much? The file system itself does not need that much
space
>>> for its own use.
>>
>> In other words, 256M limit rather disqualifies btrfs as a filesystem 
>> i.e. for /boot, doesn''t it?
> When 1G is just 10c?
Maybe when talking about traditional HDDs.
Anything flash-based is still $2-$5 per 1G.

I have some SAN devices booting off 512MB or 1G builtin flash. Having 
256M for /boot there would not leave much more space for the operating 
system.

Why separate /boot? It''s still needed for encrypted rootfs or more
fancy
partitioning (like / on LVM, at least until GRUB2 is stable and is 
shipped by major distros).


Seriously, what are the technical reasons that btrfs needs so much space 
for a minimal filesystem?

Just 2 MB is enough for mkfs.ext4 to create a valid filesystem.


Also, the patch seems to be incomplete - i.e. what will happen if we try 
to btrfs-convert a 50MB ext3 filesystem into btrfs?


-- 
Tomasz Chmielewski
http://wpkg.org
--
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

On Mon, 2009-01-05 at 16:49 +0100, Tomasz Chmielewski
wrote:
> Kaspar Schleiser schrieb:
> > Hey,
> > 
> > Tomasz Chmielewski wrote:
> >>> This has been bothering me for some time. Why does btrfs need
to have
> >>> a disk greater then 256M? I could see a much smaller limit,
say 16M
> >>> but why so much? The file system itself does not need that
much space
> >>> for its own use.
> >>
> >> In other words, 256M limit rather disqualifies btrfs as a
filesystem
> >> i.e. for /boot, doesn''t it?
> > When 1G is just 10c?
> 
> Maybe when talking about traditional HDDs.
> Anything flash-based is still $2-$5 per 1G.
> 
> I have some SAN devices booting off 512MB or 1G builtin flash. Having 
> 256M for /boot there would not leave much more space for the operating 
> system.
> 
> Why separate /boot? It''s still needed for encrypted rootfs or more
fancy
> partitioning (like / on LVM, at least until GRUB2 is stable and is 
> shipped by major distros).
> 
> 
> Seriously, what are the technical reasons that btrfs needs so much space 
> for a minimal filesystem?
This is mostly to help prevent crashes on enospc.  As we fixup the
kernel code, the 256MB limit will go away.

-chris


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