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

["Mkrtchyan, Tigran" <[e-mail]>]

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.

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.

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

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