Subject: [nfsv4] Question on FSL TTLs

From: Chuck Lever <[email-masked]>
Date: Mon, 20 Aug 2012 12:20:43 -0400

Hi-

During IETF 84's working group meeting, Rob described NSDB schema updates needed to support SMB within FedFS.  One of the changes he mentioned was that SMB/DFS wants a per-FSN TTL attribute, not a per-FSL TTL attribute as the NSDB protocol now specifies.  The FSN is generic, not per file system protocol type, so adding a TTL to the FSN would affect all subclasses of FSL.

As a matter of implementation experience, the Linux NFS server implementation caches referral information such as resolved junctions.  It uses a per-referral cache timeout rather than a per-location cache timeout.  The per-referral timeout is concocted from the minimum of the FSL TTL values under a particular FSN.

Thus we know of implementations that can use an FSN TTL.  I suspect most NFS server export cache implementations will not be able to match the granularity of an FSL TTL.

The FSL TTL seems to be intended to cap how long temporary redirecting junctions survive after a migration.  Section 2.8.2 says

> This is an upper bound for the lifetime of the cached information and a lower bound for the lifetime of the supplemental junctions. 

The draft REQUIRES file servers to maintain temporary junctions for at least as long as the FSL TTL.  It's not clear to me why administrators would want unique values for junction lifetime on different file servers, especially given the presence of file server implementations that cannot provide per-location cache timeouts.  There could be some server implementations that allow no control over the referral cache timeout.

--

I think we need to add an optional TTL attribute to the FSN accommodate SMB, but we would need some kind of sane plan for how such a TTL might be used in conjunction with any file system protocol with a per-location TTL (e.g. NFS).

Does the concept of FSL TTL fit with SMB?  Can we require SMB servers to maintain junctions for a limited time?  Or should the requirement in 2.8.2 be turned into a recommendation?

If we keep per-location TTLs, I'd like to see some guidance in the NSDB protocol draft for file server implementors who cannot provide a per-location cache timeout.  I haven't thought carefully about this, but is there an interoperability issue here for servers that implement per-referral cache timeouts or even one timeout for their whole export cache?

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com