Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220504132106.28812-1-dwysocha@redhat.com>
In-Reply-To: <20220504132106.28812-1-dwysocha@redhat.com>
From:   Daire Byrne <daire@dneg.com>
Date:   Fri, 6 May 2022 09:37:52 +0100
Message-ID: <CAPt2mGMQ2x_aQwr2W18xX5LfUy6q118QxVqhdC663ZtUjZehdg@mail.gmail.com>
Subject: Re: [PATCH] NFS: Pass i_size to fscache_unuse_cookie() when a file is released
To:     Dave Wysochanski <dwysocha@redhat.com>
Cc:     Anna Schumaker <anna.schumaker@netapp.com>,
        Trond Myklebust <trond.myklebust@hammerspace.com>,
        linux-nfs@vger.kernel.org, linux-cachefs@redhat.com,
        David Howells <dhowells@redhat.com>,
        Daire Byrne <daire.byrne@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, 4 May 2022 at 14:22, Dave Wysochanski <dwysocha@redhat.com> wrote:
>
> Pass updated i_size in fscache_unuse_cookie() when called
> from nfs_fscache_release_file(), which ensures the size of
> an fscache object gets written to the cache storage.  Failing
> to do so results in unnessary reads from the NFS server, even
> when the data is cached, due to a cachefiles object coherency
> check failing with a trace similar to the following:
>   cachefiles_coherency: o=0000000e BAD osiz B=afbb3 c=0

I can confirm that this fixes an oddity I had noticed with the "new" fscache.

When running an fio read benchmark, if you remounted or dropped caches
between reads, it seemed like it required two initial reads of the
data (and writes to cache) before all subsequent reads would come from
the fscache disk.

Tested-by: Daire Byrne <daire@dneg.com>

Cheers,

Daire