Re: [LTP] [PATCH] inode01: Increase dev_min_size to prevent ENOSPC on exfat

[Andrea Cervesato via ltp <ltp@lists.linux.it>]

Hi Wake,

the agent couldn't complete because patch didn't apply, so I will
send you the complete review from a local instance.

On Aug 31, 2026, Wake Liu wrote:
> inode01: Increase dev_min_size to prevent ENOSPC on exfat

> On exfat, each file and directory occupies at least one cluster (default
> 32 KB for volumes > 256 MB), which requires ~350 MB of data clusters.

The test does not let mkfs.exfat pick the default cluster size. Master
already forces 4 KB:

	.filesystems = (struct tst_fs[]) {
		{.type = "exfat", .mkfs_opts = (const char *const[]) {"-c", "4K", NULL}},
		{}
	},

That comes from 4bf4da8c6fda ("inode01: Configure 4KB cluster size on
exfat to prevent ENOSPC"), merged on 2026-08-13, which targets this
exact ENOSPC.

So the "default 32 KB" premise does not hold here and the ~350 MB figure
does not follow.

> The parallel scenario concurrently spawns multiple workers (default 5),
> each creating 2,185 files and directories, totaling 10,925 objects.

The object count matches. With depth=6 fanout=6 each level creates 3
dirs and 3 files, and the 3 dirs recurse, giving 2184 objects plus the
per-worker root created at inode01.c:214, so 2185 per worker and 10925
in total.

But at the 4 KB cluster size actually in use that is ~43 MB, not
~350 MB. Each file holds repetitions=8 records of strlen(path) bytes
(inode01.c:60-61), well under one cluster, and each directory holds only
6 entries, so every object costs exactly one cluster.

512 MB leaves roughly an order of magnitude of headroom.

>   inode01.c:61: TBROK: write(3,...) failed: ENOSPC (28)
>   inode01.c:64: TBROK: mkdir(...) failed: ENOSPC (28)

This is the same file and the same two line numbers as the log already
quoted in ecf418722780. Was this reproduced on a tree that contains
4bf4da8c6fda?

If the failure is still real there, the numbers above say the cause is
not the cluster size, and doubling the device would hide it rather than
fix it. Could a fresh log be posted together with the geometry mkfs.exfat
actually produced (its output, or dumpexfat on the formatted device)?

> -	.dev_min_size = 512,
> +	.dev_min_size = 1024,

dev_min_size is not only the loop device size. With .all_filesystems = 1
tmpfs is also exercised (lib/tst_supported_fs_types.c:34), and the tmpfs
mount is sized from it (lib/tst_test.c:1246-1268):

	if (!tst_test->dev_min_size)
		tmpfs_size = 32;
	else
		tmpfs_size = tdev.size;

	if ((tst_available_mem() / 1024) < (tmpfs_size * 2))
		tst_brk(TCONF, "No enough memory for tmpfs use");

tdev.size is the acquired device size (lib/tst_test.c:1573), so this
raises the available-memory requirement from 1 GB to 2 GB.

That tst_brk() runs inside prepare_device(), which run_tcase_on_fs()
calls in the parent before fork_testrun() (lib/tst_test.c:1984-1997), so
it aborts the whole run rather than skipping the tmpfs pass.

There is no per-filesystem way out either: dev_min_size is global, and
struct tst_fs.mkfs_size_opt can only limit a filesystem below the device
size (include/tst_test.h:267-270).

Given the ~43 MB actual footprint, is this cost intended?

Verdict - Needs revision

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp