Re: [PATCH] mkfs.ubifs: Add option to minimize the amount of LEBs

From: Richard Weinberger <richard@nod.at>
To: Mauri Sandberg <maukka@ext.kapsi.fi>
Cc: david oberhollenzer <david.oberhollenzer@sigma-star.at>,
	 linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH] mkfs.ubifs: Add option to minimize the amount of LEBs
Date: Sat, 6 Jan 2024 16:23:28 +0100 (CET)	[thread overview]
Message-ID: <1464457733.203332.1704554608470.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <022816c4-7afd-4bd9-80a7-6bd5e9e0edd0@ext.kapsi.fi>

----- Ursprüngliche Mail -----
> Von: "Mauri Sandberg" <maukka@ext.kapsi.fi>
> An: "richard" <richard@nod.at>
> CC: "Mauri Sandberg" <maukka@ext.kapsi.fi>, "david oberhollenzer" <david.oberhollenzer@sigma-star.at>, "linux-mtd"
> <linux-mtd@lists.infradead.org>
> Gesendet: Samstag, 6. Januar 2024 15:46:11
> Betreff: Re: [PATCH] mkfs.ubifs: Add option to minimize the amount of LEBs

> Thanks for your propmpt response, Richard.
> 
> On 6.1.2024 12.16, Richard Weinberger wrote:
>> But what will happen if somebody tries to
>> use a minimized UBIFS in rw-mode?
>> I fear then UBIFS will fail because it has not enough log LEBs or such?
> 
> First off I would assume it would mount the filesystem writable with
> very little free space available. Here I am assuming the mininum LEB
> count mkfs.ubifs calculates is legit and that the same goes for the
> journal and log sizes.

Hm, I gave your patch a try. As soon I use "-M", the resulting file system
does not mount. No matter how large the UBI volume is.

[18034.687392] UBIFS (ubi0:0): Mounting in unauthenticated mode
[18034.688241] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 1428
[18034.688484] UBIFS error (ubi0:0 pid 1427): check_lpt_type.constprop.19: invalid type (0) in LPT node type 1
[18034.690139] CPU: 2 PID: 1427 Comm: mount Not tainted 6.7.0-rc7-00004-gc07a4dab243a #246
[18034.690871] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014
[18034.690873] Call Trace:
[18034.690886]  <TASK>
[18034.690889]  dump_stack_lvl+0x32/0x50
[18034.690899]  check_lpt_type.constprop.19+0x36/0x40
[18034.690905]  ubifs_unpack_nnode+0x4a/0x120
[18034.690910]  ubifs_read_nnode+0x1bf/0x210
[18034.690913]  ubifs_lpt_lookup_dirty+0x165/0x2e0
[18034.690916]  ? leb_write_unlock+0x72/0xc0
[18034.690920]  ubifs_replay_journal+0x44/0x11d0
[18034.690922]  ? next_sqnum+0x27/0x90
[18034.690926]  ? ubifs_leb_write+0x5f/0x100
[18034.695675]  ? ubifs_write_node_hmac+0xcd/0x1d0
[18034.695679]  ubifs_mount+0x1305/0x17d0
[18034.695682]  ? __pfx_bud_wbuf_callback+0x10/0x10
[18034.695684]  ? legacy_get_tree+0x22/0x40
[18034.695688]  ? __pfx_ubifs_mount+0x10/0x10
[18034.695690]  legacy_get_tree+0x22/0x40
[18034.695692]  vfs_get_tree+0x20/0xd0
[18034.695695]  path_mount+0x59c/0x9a0
[18034.695698]  ? user_path_at_empty+0x3b/0x50
[18034.695702]  do_mount+0x74/0x90
[18034.695704]  __x64_sys_mount+0x81/0xe0
[18034.695706]  do_syscall_64+0x42/0xf0
[18034.695711]  entry_SYSCALL_64_after_hwframe+0x6f/0x77

> Also, my current understanding is that the LEB calculation is based on
> uncompressed size. If ubi uses compression runtime then the amount of
> LEBs actually used is smaller, no?

I don't think this matters much here. The LEB calculation in mkfs is to
make sure UBIFS has enough space on the resulting UBI volume to work correctly.
E.g. Space for the log, etc..

> I'll have to do some tests on the topic and see how it behaves. I'll get
> back to you.

Ok!

Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/