[nfsv4] Re: New Version Notification for draft-haynes-nfsv4-uncacheable-03.txt

[Thomas Haynes <[e-mail]>]

> On Mar 24, 2025, at 1:32 PM, Mkrtchyan, Tigran <[e-mail]> wrote:
> 
> Hi Tom,
> 
> I have mixed feeling about this proposal. From one side, it make sense. For example, we have virtual directories and their content is dynamically changes. Thus, any getattr will tell that directory is modified. This is of course bad, as those virtual directories are not modified that often. On the other hand, server NFS should not take over client cache control. Maybe such a behavior is covered by directory delegations? At least, the document should discuss why it not appropriate (too many recall, etc…) So, I think, the attribute should be a hint, telling client that directory/file changes more often than might be expected. It‘s up to client to respect the hint or not.
> 

Hi Tigran,

Then you have a local policy to not allow the uncacheable attribute to be set in this virtual directories?

How it is a hint? The intent has nothing to do with the change rate of the attributes and everything to do with whether or not a user has access to a directory listing.

Further, the server has no knowledge that the client has a dirent cache.






> For files, the story is even more interesting. The HPC applications typically have their own way to communicate that data is modified, for example with MPI-IO. However, the applications have no way to enforce read operations to by-pass filesystem cache. Nonetheless, if file is not modified, the cache reads are perfectly valid.


But NFSv4.2 has no access to proprietary protocols. And the intent is that the NFS client will force the applications to have reads bypass the cache.

> 
> So, I think, the draft have identified the problem, but I am not convicted (yet) that it proposes the right solution.


Thanks for the feedback, the issue is that the problem statement appears simple, but the writing is not.

FWIW - we have prototyped this in the Linux kernel - not sure about the results - just that we have it.


> 
> Best regards,
> — Tigran
> 
>> On 22. Mar 2025, at 01:06, Thomas Haynes <[e-mail]> wrote:
>> 
>> Hi,
>> 
>> I’d like to push for the NFSv4 WG to adopt this draft as a WG item.
>> 
>> Thanks,
>> Tom
>> 
>>> Begin forwarded message:
>>> 
>>> From: [e-mail]
>>> Subject: New Version Notification for draft-haynes-nfsv4-uncacheable-03.txt
>>> Date: March 22, 2025 at 9:04:24 AM GMT+9
>>> To: "Thomas Haynes" <[e-mail]>
>>> 
>>> A new version of Internet-Draft draft-haynes-nfsv4-uncacheable-03.txt has been
>>> successfully submitted by Thomas Haynes and posted to the
>>> IETF repository.
>>> 
>>> Name:     draft-haynes-nfsv4-uncacheable
>>> Revision: 03
>>> Title:    Adding an Uncacheable Attribute to NFSv4.2
>>> Date:     2025-03-21
>>> Group:    Individual Submission
>>> Pages:    9
>>> URL:      https://www.ietf.org/archive/id/draft-haynes-nfsv4-uncacheable-03.txt
>>> Status:   https://datatracker.ietf.org/doc/draft-haynes-nfsv4-uncacheable/
>>> HTML:     https://www.ietf.org/archive/id/draft-haynes-nfsv4-uncacheable-03.html
>>> HTMLized: https://datatracker.ietf.org/doc/html/draft-haynes-nfsv4-uncacheable
>>> Diff:     https://author-tools.ietf.org/iddiff?url2=draft-haynes-nfsv4-uncacheable-03
>>> 
>>> Abstract:
>>> 
>>>   The Network File System version 4.2 (NFSv4.2) allows a client to
>>>   cache both metadata and data for file objects, as well as metadata
>>>   for directory objects.  While caching directory entries (dirents) can
>>>   improve performance, it can also prevent the server from enforcing
>>>   access control on individual dirents.  Similarly, caching file data
>>>   can lead to performance issues if the cache hit rate is low.  This
>>>   document introduces a new uncacheable attribute for NFSv4.  Files and
>>>   dirents marked as uncacheable MUST NOT be stored in client-side
>>>   caches.  This ensures data consistency and integrity by requiring
>>>   clients to always retrieve the most recent data directly from the
>>>   server.  This document extends NFSv4.2 (see RFC7862).
>>> 
>>> 
>>> 
>>> The IETF Secretariat
>>> 
>>> 
>>