Re: Possible regression after NFS eof page pollution fix (ext4 checksum errors)

[Trond Myklebust <trondmy@kernel.org>]

On Sun, 2026-01-11 at 09:03 +0200, 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 believe in your previous email you had it set as "unmap":

{"driver":"file","filename":"/images/.libvirt/linux-VAGRANTSLASH-
upstream_Z.img","node-name":"libvirt-2-storage","auto-read-
only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-
format","read-only":true,"driver":"qcow2","file":"libvirt-2-
storage","backing":null} -blockdev
{"driver":"file","filename":"/images/.libvirt/Y.img","node-
name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}

However if you've already tested with "ignore" and it didn't make a
difference then let's not worry about it.

> 
> > 
> > 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.

Thanks!
-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com