NFS Best Practices

The problem Implementations arising –Document best practices where choice exists –Document behaviour where protocol spec is silent Moving drafts forward –Pruning and bug fixing Way behind

Target is implementation table Feature choices by implemention Sample tables to follow are incomplete –Need to work with implementers to document

Security SolarisAIXEMCBSDNetAppHumm- ingbird Linux ACLsServer client n/a YesServer Client LIPKEYNo Partial KerberosAuth Integ Privacy n/aAuth Integ Privacy ACL description is complex - along lines of interpretation - Posix vs. NFS V4 For Linux server, say, dependent on underlying OS

Delegations SolarisAIXEMCBSDNetAppHumm- ingbird Linux ReadServer Client n/a ServerN/aServer Client WriteServer Client N/a ServerN/aServer Client Client has choices of behaviour on delegation –Ignore –Manage data, lock over wire –Close files, retain delegation

Named attributes SolarisAIXEMCBSDNetAppHumm- ingbird Linux AvailServer Client n/a ServerN/a # supported N/a Size Limit NoneN/a NoneN/a??? Behaviour is loosely defined in RFC

Magic numbers SolarisAIXEMCBSDNetAp p Humm- ingbird Linux Lease timeout90 secsn/a N/a Max delegations N/a Max sz COMPOUND N/a NoneN/a # of operations, max size of COMPOUND request

Miscellaneous domain attributed Ids, UID space considerations Does client react to migration feedback What minor versions (in future) supported

Terra incognita What is not defined by protocol –Global name space –And more? Any issues with moving from NFS Version 3 to NFS Version 4? –It depends on what the definition of “transparent” is…

Questions Much more work here