Network File System Version 4 WG
November 7, 2024 15:30 - 17:00
Agenda
Detailed Minutes
Note well, note really well.
Meetecho was only a little flaky today.
Chairs (10 min)
Interim meetings are resuming on Nov 20. They will happen every other
week and happen 3pm every Wednesday. We'll push to get minutes out for
interim meetings.
Partucpants to post to list on docs in progress. To show that they are
being reviewed. We need people to say the docs are good to go.
WG groups in progress
• draft-ietf-nfsv4-rfc5661bis-09
• draft-ietf-nfsv4-layrec-02 – IESG review
• draft-ietf-nfsv4-layoutwcc-04 – In IETF last call
• draft-ietf-nfsv4-delstid-08 – RFC editor queue
• draft-ietf-nfsv4-internationalization-11 – WGLC
Not yet adopted Documents
• draft-haynes-nfsv4-erasure-encoding-03
• draft-haynes-nfsv4-mojette-encoding-00
• draft-haynes-nfsv4-uncacheable-01
• draft-mzhang-nfsv4-recursively-setting-06
• draft-dnoveck-nfsv4-rfc5662bis-05
• draft-rmacklem-nfsv4-posix-acls-10
• draft-dnoveck-nfsv4-security-11
• draft-dnoveck-nfsv4-acls-05
• [stopping at August or newer]
delstateid coverage at Bakeathom, according to Haynes. beepy to forward
Bakeathon status from Steve Dickson. Macklem gave a brief update of
bakeathon.
Internationalization (5 min)
We need to say we're good to go on WG docs in progress in WG. To
actually advance documents (Chris) we need to say go or no go
individually on the mail list.
Hellwig is good to go on I18N and he thinks we should not spend time on
4.0. Chris will take 4.0 support to list.
Flex File v2 Erasure Encoding (15 min)
Scaling, performance on parallel writes is goal of client side erase
coding. Block-based, staging and recovery. Haynes has a good diagram in
the slides.
client_id and change_id on each clock to ensure consistency. Integrity
via CRC.
Goal of layout mgmt is to keep erasure coding consistency, not solve the
long standing lacking of consistent writes from different clients in the
absence of explicit locking.
Hellwig is concerned of write amplifiction on the MDS - 30+ bytes being
added just to manage the erasure coding metadata consistency. Hellwig
would like an attack to simplify. Look into an intent based approach to
writing the related data blocks. He feels it will be useful outside the
erasure coding constitute.
Haynes - this is early work, looking for feedback before going much
further with design.
Trond - the intention here is to ensure data is never corrupted - by the
erasure coding mechanisms. Not solve the POSIX semantic non-overlapping
write consistency issue. Complexity in trying to do this over the
network compared to a single RAID array.
Hellwig thinks declustered RAID approach might help here. Linear address
space with fixed mapping - two things. One, write out of place and swap,
or two, Hayne's proposal.
Haynes - we have to step back and look at both approaches.
Adding Uncacheable Attr (5 min)
Haynes - access based enumeration, force access check to server / client
to not cache. Second, avoic client page cache similar to O_DIRECT.
Trons - not only about not caching attributes, but not caching contents.
Hellwig concerned about performance on metadat, otherwise it looks ok.
For data, make sure that semantic matches the commit mode.
Macklem - raised question of what if one client adheres to policy, other
client does nots. Haynes said that is would be attribute inherited from
directory (?). Macklem was ok with that.
Recursive Attributes (15 min)
Rijesh Parambattu presenting.
Solving the problem of many sequential READDIR and SETATTR requests when
recursively chnaging attributes in a directory tree.
Proposing new ops for the COMPOUND operation. Four operatons - see
slides. Both synchroous and asynchronous operations proposed.
Haynes - how are partial failures handled - permissions issues within
tree. Rijesh will add material to draft. Haynes asks what about of
crossing the file system? Need to follow up on this.
Trond - how do server implementers build this to scale? Millions of
directories and hundreds of millions of files - can result in a
significant server load (that beepy says may impact many other clients).
Perhaps time limit for out of control recursive operation - beepy.
Hellwig trod similar ground.
Hellwig said there can be many different object types in a tree. Sybolic
links? Devices?
Macklem says client would have to purge client caches because the server
may not do what you expect on the chnaging attributes. You would then
perhaps be re-reading the same file attributes later.
POSIX ACL (15 min)
Rick Macklem - proposal came out of Dave Noveck work. Macklem thinks it
is an unsolvable problem.
Servers often save a "true form" of ACLs. A transpose of the NFS Version
4 ACL to local file system 4.
Rick is proposing a TRUE_FORM approach where POSIX ACLs of some sort
are supported. (look at transcript and proposal)
emails this morning from Trond and Chuck asking how to compare two POSIX
draft ACLs.
Hellwig saus the work is great. Hellwig thinks VERIFY is deadwod in the
spec. In FreeBSD it is used for TYPE and SIZE. But ... not guaranteed to
work correctly. And we should verify that we have rights to use POSIX
(which is trademark of IEEE) for a retracted draft. David Black may have
said the Usenix paper may be sufficient.
Hellwig - the only part I find scary is scope. System scope vs. file
system scope. For file or object mode bit calculations can go wrong, and
scope.
Trond - on VERIFY, the mask also causes a problem.
ACL Redux (10 min)
Authentication & Authorization (5 min)
5661bis / security (10 min)
Noveck said errata accumulated over 15 years for 5662 and 5662 docs. We
decided to factor out I18N and Security. Drafting has gone on for years.
Noveck wants to push this over the hump and get this done.
The smaller docs (I18N) are progressing better.
Noveck wants adoption of the ACL draft. I18N seems ready to go. Security
has languished for two years - we must proceed on adoption process.
5661 is there.
Hellwig, the reason they are not adopte is there is not consensus on
adoption. On 5661-bis, it is difficult to determine what has changed as
it has not been under source control. Does not know how to proceed.
Zahed - sees ... confusion. David has been working on this almost alone.
But if the working group des not want or need it - we have to drop them,
we can't hang on (without progress) for another two years. Are the
documents improving things or making things worse.
Zahed wants this working group to come to a conclusion.
Macklem suggests factoring out informational doc to reduce security
info. Thinks about RFC 7530 and ??? (transcript).
beepy gave some history. The document split up was intended to simplify
consumption of the documents by people outside working group, But the
unintended side effect in part was that determining differences in te
5661-bis document was made more complicated.
Hellwig - problem is management of the large -bis document without
source control makes it very difficult to understand the changes and the
motivations for them. beepy said Dave tried to give reviewer's guides,
but we're struggling.
Chris - has tried for the past ten months to get security deployed for
NFS as part of inspection of the security document (using Kerberos in a
brown field). It is very difficult. Agrees with Zahed - we're not making
the progress we need to do.
Zahed - we are here, let's figure out a plan. Just wants the WG to
decide how to move forward or the IESG will have to.
AOB