From: Rich Felker <dalias@libc.org>
To: Stephen Von Takach <steve@place.technology>
Cc: musl@lists.openwall.com, Viv Briffa <viv@place.technology>
Subject: Re: unlink on NFS volume fails silently
Date: Thu, 10 Jul 2025 11:44:15 -0400 [thread overview]
Message-ID: <20250710154414.GU1827@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAASffotazEgv9gxCjeC+sh8E2bWZE2ZZhQnqypaEnwJc_5w6hw@mail.gmail.com>
On Thu, Jul 10, 2025 at 02:58:30PM +1000, Stephen Von Takach wrote:
> Yeah I see your point and this was closed as a kernel issue:
> https://gitlab.alpinelinux.org/alpine/aports/-/issues/10960
OK, is your issue unlink falsely succeeding, or readdir skipping
entries? The latter is a known bug in the kernel NFS client. One of my
comments on the tracker suggests:
"The nordirplus option mentioned in one of those tracker threads
might be a workaround."
I'm not sure if this is the case, but it might be worth trying.
Note that it's *expected* that an already-in-progress iteration of a
directory may return entries that were already deleted. The
unacceptable thing is the opposite: when it skips some entries that
have not been deleted as a consequence of other things being deleted.
> We're running these two containers on the same kernel and seeing the same
> behaviour as that alpine issue.
> Happy to continue working around the issue by using debian userspace to
> build our service.
>
> It does seems crazy that there is clearly an issue, possibly a kernel issue
> that is being handwaved away by all parties
It's not "handwaved away" by us. We have determined that there is a
bug in a component we have no control over, and for which we have no
sound means of working around.
I'm happy to work together on tracking down the cause to get it fixed,
but that requires cooperation from someone who's able to reproduce it,
documenting the exact circumstances under which it occurs (NFS server
vendor/version, NFS mount options) and either producing a minimal test
program to reproduce the issue under those conditions, or being
willing to run a proposed test by someone else.
Even if using Debian/glibc *seems* to make things work for you, I
think it would be beneficial for you to try to get to the root cause
of the problem and get it fixed. What we previously found on the
above-linked ticket was that glibc is not doing anything special that
should rule out that bug, only that the particular filename
sizes/counts in the test didn't trigger the bug with glibc.
Again, I don't know if this is the same bug you're hitting (this is
the first time in the thread you've mentioned readdir if I'm not
mistaken, as opposed to just unlink) or if there's a second bug in
play here. If you could at least clarify that, it would be a big help
to anyone investigating it in the future.
Rich
next prev parent reply other threads:[~2025-07-10 15:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-06 6:25 [musl] unlink on NFS volume fails silently Stephen Von Takach
2025-07-07 18:26 ` Markus Wichmann
2025-07-08 1:08 ` Rich Felker
2025-07-09 3:59 ` [musl] " Stephen Von Takach
2025-07-09 18:41 ` Rich Felker
2025-07-09 23:01 ` [musl] " Stephen Von Takach
2025-07-10 0:03 ` Rich Felker
2025-07-10 4:58 ` Stephen Von Takach
2025-07-10 15:44 ` Rich Felker [this message]
2025-07-10 17:01 ` Nathan McSween
2025-07-10 17:11 ` Rich Felker
2025-07-10 21:25 ` Stephen Von Takach
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=20250710154414.GU1827@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
--cc=steve@place.technology \
--cc=viv@place.technology \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).