From: "Darrick J. Wong" <djwong@kernel.org>
To: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Cc: Zorro Lang <zlang@redhat.com>,
fstests@vger.kernel.org, Disha Goel <disgoel@linux.ibm.com>
Subject: Re: [PATCH] generic/645: Confirm availability of free inodes
Date: Wed, 29 Jul 2026 08:44:51 -0700 [thread overview]
Message-ID: <20260729154451.GB7371@frogsfrogsfrogs> (raw)
In-Reply-To: <ammQvzfsFTx9EEmm@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>
On Wed, Jul 29, 2026 at 11:06:57AM +0530, Ojaswin Mujoo wrote:
> On Thu, Jun 25, 2026 at 11:42:59AM -0700, Darrick J. Wong wrote:
> > On Wed, Jun 17, 2026 at 11:12:16AM +0530, Ojaswin Mujoo wrote:
> > > When running generic/645 with ext4 using 64k block size + bigalloc, the
> > > test fails with ENOSPC because the filesystem runs out of inodes before
> > > the test completes.
> > >
> > > The test creates approximately 10,001 files, however, in this particular
> > > configuration a standard 5G FS only has around ~5100 inodes resulting in
> > > the ENOSPC failure.
> > >
> > > Add a check using _get_free_inode() to verify sufficient inodes are
> > > available before running the test, else skip it.
> > >
> > > Reported-by: Disha Goel <disgoel@linux.ibm.com>
> > > Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
> > > ---
> > > tests/generic/645 | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/tests/generic/645 b/tests/generic/645
> > > index d6eb75e6..944b33db 100755
> > > --- a/tests/generic/645
> > > +++ b/tests/generic/645
> > > @@ -19,6 +19,12 @@ _require_chown
> > > _wants_kernel_commit dacfd001eaf2 \
> > > "fs/mnt_idmapping.c: Return -EINVAL when no map is written"
> > >
> > > +_free_inodes=$(_get_free_inode $TEST_DIR)
> > > +if [ $_free_inodes -ne 0 ] && [ $_free_inodes -lt 10001 ]; then
> >
> > I'm assuming the > 0 check here is to cover weird filesystems like fat
> > that don't advertise any inodes? /me wonders if that ought to be a
>
> Hey Darrick, sorry I missed this email earlier. Yes that's the idea. I
> see there is a helper already
>
> _require_inode_limits()
> {
> if [ $(_get_free_inode $TEST_DIR) -eq 0 ]; then
> _notrun "$FSTYP does not have a fixed number of inodes available"
> fi
> }
>
> But this will end up skipping the FSes that don't have a concept of
> free inodes.
>
> > common helper where we can record that justification:
> >
> > _require_free_inodes() {
> > local path="$1"
> > local nr="$2"
> >
> > local _free_inodes=$(_get_free_inode "$path")
> >
> > # Weird filesystems like vfat don't report any inodes, so we
> > # can't check for sufficient free inodes; IOWs, FAFO.
> > test "$_free_inodes" -eq 0 && return
>
> If we do this, won't we pass the check for the case where say xfs has 0
> free inodes. It's a rare chance IMObut still wondering if we want to
> keep that edge case open.
>
> What do you think in these options:
> - use the above check
> - use _require_free_inodes which will cause notruns on some FSes
> - Maybe have a new helper to check if FS advertises free inodes and then
> use somthing like
>
> if ! __fs_advertises_free_inodes
> return
> else
> test "$_free_inodes" -lt "$nr" && \
> _notrun "Insufficient free inodes ($_free_inodes), need at least $nr"
>
Hmmm. This is getting complicated, because generic tests can run on any
filesystem and we have no idea how much space an inode actually
consumes, or if the filesystem even has any real concept of inodes.
Can we instead check the vfstest output for the ENOSPC error message and
_notrun it if that is found?
--D
> Regards,
> ojaswin
>
> >
> > test "$_free_inodes" -lt "$nr" && \
> > _notrun "Insufficient free inodes ($_free_inodes), need at least $nr"
> > }
> >
> >
> > _require_free_inodes $TEST_DIR 10001
> >
> > (maybe clean up the comment a bit)
>
> >
> > --D
> >
> > > + _notrun "Insufficient free inodes ($_free_inodes), need at least 10001"
> > > +fi
> > > +
> > > echo "Silence is golden"
> > >
> > > $here/src/vfs/vfstest --test-nested-userns \
> > > --
> > > 2.53.0
> > >
> > >
>
next prev parent reply other threads:[~2026-07-29 15:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-17 5:42 [PATCH] generic/645: Confirm availability of free inodes Ojaswin Mujoo
2026-06-25 18:42 ` Darrick J. Wong
2026-07-29 5:36 ` Ojaswin Mujoo
2026-07-29 15:44 ` Darrick J. Wong [this message]
2026-07-30 11:03 ` Ojaswin Mujoo
2026-07-30 15:32 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260729154451.GB7371@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=disgoel@linux.ibm.com \
--cc=fstests@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=zlang@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox