Re: [Buildroot] [PATCH 1/1] fs/ubifs: increase logical eraseblock size

Re: [Buildroot] [PATCH 1/1] fs/ubifs: increase logical eraseblock size

[Bernd Kuhls]

Am Sat,  8 Jul 2023 18:36:44 +0200 schrieb Bernd Kuhls:

>  config BR2_TARGET_ROOTFS_UBIFS_LEBSIZE
>  	hex "logical eraseblock size"
> -	default 0x1f800
> +	default 0x3f800

Hi,

or better update utils/genrandconfig like this?
https://git.busybox.net/buildroot/commit/?id=3c98eb26db6501a373cc405c80505ba72fde9e96

Regards, Bernd

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] fs/ubifs: increase logical eraseblock size

[Thomas Petazzoni via buildroot]

On Sun, 09 Jul 2023 14:39:10 +0200
Bernd Kuhls <bernd@kuhls.net> wrote:

> or better update utils/genrandconfig like this?
> https://git.busybox.net/buildroot/commit/?id=3c98eb26db6501a373cc405c80505ba72fde9e96

Yes, setting BR2_TARGET_ROOTFS_UBIFS_MAXLEBCNT to a larger value in
genrandconfig would make more sense I believe. You can set is to 5GB
divided by 0x1f800, to match what is done for other filesystems (they
assume the rootfs will never grow beyond 5GB).

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 1/1] fs/ubifs: increase logical eraseblock size

[Bernd Kuhls]

This value is unchanged since 2008 and too small for current images.

Fixes:
http://autobuild.buildroot.net/results/f72/f72918d63510b170e5da01bfa9c247cf9dcf507f/

Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
---
There is no particular reason for the new value, it was just the first
value I found working for this defconfig while increasing it in steps
of 0x10000.

 fs/ubifs/Config.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ubifs/Config.in b/fs/ubifs/Config.in
index e79ab9a17e..bad26bf99f 100644
--- a/fs/ubifs/Config.in
+++ b/fs/ubifs/Config.in
@@ -7,7 +7,7 @@ if BR2_TARGET_ROOTFS_UBIFS
 
 config BR2_TARGET_ROOTFS_UBIFS_LEBSIZE
 	hex "logical eraseblock size"
-	default 0x1f800
+	default 0x3f800
 	help
 	  Logical eraseblock (LEB) size. The value provided here is
 	  passed to the -e/--leb-size option of mkfs.ubifs.
-- 
2.39.2

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] fs/ubifs: increase logical eraseblock size

[Thomas Petazzoni via buildroot]

On Sat,  8 Jul 2023 18:36:44 +0200
Bernd Kuhls <bernd@kuhls.net> wrote:

> This value is unchanged since 2008 and too small for current images.
> 
> Fixes:
> http://autobuild.buildroot.net/results/f72/f72918d63510b170e5da01bfa9c247cf9dcf507f/
> 
> Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
> ---
> There is no particular reason for the new value, it was just the first
> value I found working for this defconfig while increasing it in steps
> of 0x10000.
> 
>  fs/ubifs/Config.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/ubifs/Config.in b/fs/ubifs/Config.in
> index e79ab9a17e..bad26bf99f 100644
> --- a/fs/ubifs/Config.in
> +++ b/fs/ubifs/Config.in
> @@ -7,7 +7,7 @@ if BR2_TARGET_ROOTFS_UBIFS
>  
>  config BR2_TARGET_ROOTFS_UBIFS_LEBSIZE
>  	hex "logical eraseblock size"
> -	default 0x1f800
> +	default 0x3f800

This doesn't make sense, and in fact doesn't really solve the issue at
http://autobuild.buildroot.net/results/f72/f72918d63510b170e5da01bfa9c247cf9dcf507f/build-end.log.

The issue at
http://autobuild.buildroot.net/results/f72/f72918d63510b170e5da01bfa9c247cf9dcf507f/build-end.log
is that the *number* of LEBs in insufficient, i.e the size of the image
is too small to contain the root filesystem contents.

What your patch is doing is changing the size of the LEB, but the size
of the LEB is intimately related to the NAND flash geometry. You can't
just change it randomly. So yes, by extending the LEB size, you're less
likely to encounter the "max_leb_cnt too low" error because with a
larger LEB size, you have more space for a given number of LEBs, but
you're not fixing the real issue, which is bound to happen again with a
larger root filesystem.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot