Add an NFSv4.1 server #142
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
That way we can create an NFSv4.1 server next to it.
This issue was fixed in macOS 13.3, which is also the minimum supported version we document in virtual.proto.
This requires less copy-pasting between these implementations.
EdSchouten
force-pushed
the
eschouten/20240702-nfs41
branch
2 times, most recently
from
5fb902a
to
78168d3
Compare
You see that most other NFS server implementations combine NFSv4.0 and NFSv4.1 into a single server. For our use case this isn't necessary, because we always know which exact minor version clients are going to use. We can thus provide separate implementations. Furthermore, I'm not convinced that combining both versions into a single server is desirable from a code maintenance perspective. Even though 4.1 is only 2.5% more than 4.0, the differences between both protocols are quite substantial: - The NFSv4.0 way of registering clients with SETCLIENTID and SETCLIENTID_CONFIRM has been completely replaced by EXCHANGE_ID and CREATE_SESSION. - Transactions using sequence IDs on open-owners and lock-owners have been completely replaced by SEQUENCE. - With NFSv4.0, the client ID has to be derived from state IDs, meaning state IDs are globally unique. With NFSv4.1, the client ID has to be derived from the sequence ID that is provided to SEQUENCE. State IDs are now scoped to a client. With that in mind, this change adds a new server type that implements NFSv4.1 with complete disregard for compatibility with NFSv4.0, though it does borrow a lot of code from the NFSv4.0 server. The protocol changes described above require a completely different approach to locking. The NFSv4.0 server is protected by a single lock that we only needed to acquire for a subset of requests. With NFSv4.1 we need to perform some locking for every request, because almost all of them will start with SEQUENCE. Fortunately, with state IDs now being scoped to clients, it's easy to add fine-grained locking: - Clients, sessions and slot are protected by mutex nfs41Program.clientsLock. - Open-owners and lock-owners are protected by read-write lock clientIncarnationState.lock. Except when a client is fully idle, as then we can use nfs41Program.clientsLock. - Opened files are protected by read-write lock nfs41Program.openedFilesLock. - Byte-range lock sets are protected by read-write lock nfs41OpenedFileState.locksLock.
Add a 'minorVersion' configuration option that can be used to explicitly choose between NFSv4.0 or NFSv4.1. Default to NFSv4.0, because that's what macOS supports.
EdSchouten
force-pushed
the
eschouten/20240702-nfs41
branch
from
78168d3
to
8e0b59d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Right now we provide an NFSv4.0 server. This works pretty well, but the downside of NFSv4.0 is that it's only capable of processing OPEN/CLOSE/LOCK/LOCKU requests belonging to a single open/lock-owner sequentially. On macOS, every user ID gets its own open/lock-owner, meaning that performance is pretty bad when workers are concurrent.
This change solves that by adding an NFSv4.1 server. In terms of implementation it is mostly disjoint from the NFSv4.0 server. The reason being that the protocols differ substantially. Trying to provide a single server that supports both will end up being very messy.