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

[Wake Liu]

Hey Andrea,

Thanks for catching this and for the detailed review!

Ah, my apologies—I was working off an outdated tree and missed
4bf4da8c6fda. With 4KB clusters already in place, this patch is
definitely redundant and would only unnecessarily inflate the tmpfs
memory requirement.

Let's go ahead and drop this one. Thanks again for looking into it!

Best,
Wake


On Mon, Aug 31, 2026 at 4:45 PM Andrea Cervesato
<andrea.cervesato@suse.com> wrote:
>
> 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



-- 
Best Regards,
Wake Liu