From: Trond Myklebust <trondmy@kernel.org>
To: Mark Bloch <mbloch@nvidia.com>
Cc: Linoy Ganti <lganti@nvidia.com>,
Bar Friedman <bfriedman@nvidia.com>,
linux-nfs@vger.kernel.org, Maor Gottlieb <maorg@nvidia.com>
Subject: Re: Possible regression after NFS eof page pollution fix (ext4 checksum errors)
Date: Thu, 22 Jan 2026 16:13:55 -0500 [thread overview]
Message-ID: <48d4e00bd1e37b95e21f2afac15e8fc96c06b868.camel@kernel.org> (raw)
In-Reply-To: <9871411e-8272-4f95-80f0-2b86e55231b8@nvidia.com>
On Thu, 2026-01-22 at 12:00 +0200, Mark Bloch wrote:
>
>
> On 11/01/2026 9:03, Mark Bloch wrote:
> > Hi Trond,
> >
> > On 11/01/2026 2:24, Trond Myklebust wrote:
> > > Hi Mark,
> > >
> > > On Mon, 2026-01-05 at 10:20 -0500, Trond Myklebust wrote:
> > > >
> > > > OK so if I'm understanding correctly, this is organised as ext4
> > > > partitions that are stored in qcow2 images that are again
> > > > stored on a
> > > > NFSv4.2 partition.
> > > >
> > > > Do these qcow2 images have a file size that is fixed at
> > > > creation
> > > > time,
> > > > or is the file size dynamic?
> >
> > The file size is dynamic (with a fixed maximum of 35 GB).
> >
> > > > Also, does changing the "discard" option from "unmap" to
> > > > "ignore"
> > > > make
> > > > any difference to the outcome?
> >
> > The discard option is already set to "ignore" in the image.
> > Do you want us to test the other options just to see if it makes
> > a difference?
> >
> > >
> > > I've been staring at this for several days now, and the only
> > > candidate
> > > for a bug in the NFS client that I can see is this one. Can you
> > > please
> > > check if the following patch helps?
> >
> > Thanks for the patch, I'll let the team dealing with the issue know
> > and let them test the patch.
> > I'll update once I know anything.
>
> We've been testing your patch for some time now and didn't hit the
> issue.
> Feel free to add Bar's tested by tag as she was the one
> that actually tested the fix. Thanks for looking into this.
>
> Tested-by: Bar Friedman <bfriedman@nvidia.com>
>
> Mark
>
Thank you very much for testing, Bar! I unfortunately already sent the
patch upstream as it was clearly a necessary fix (even though it was
not obvious to me that it would be sufficient to fix your reported
problem). I'm therefore hoping it will hit the 6.18.x stable kernels
soon.
>
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com
prev parent reply other threads:[~2026-01-22 21:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-04 9:16 Possible regression after NFS eof page pollution fix (ext4 checksum errors) Mark Bloch
2026-01-04 15:36 ` Trond Myklebust
2026-01-05 14:00 ` Mark Bloch
2026-01-05 15:20 ` Trond Myklebust
2026-01-06 10:12 ` Bar Friedman
2026-01-11 0:24 ` Trond Myklebust
2026-01-11 7:03 ` Mark Bloch
2026-01-11 14:59 ` Trond Myklebust
2026-01-22 10:00 ` Mark Bloch
2026-01-22 21:13 ` Trond Myklebust [this message]
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=48d4e00bd1e37b95e21f2afac15e8fc96c06b868.camel@kernel.org \
--to=trondmy@kernel.org \
--cc=bfriedman@nvidia.com \
--cc=lganti@nvidia.com \
--cc=linux-nfs@vger.kernel.org \
--cc=maorg@nvidia.com \
--cc=mbloch@nvidia.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