On 4 Jan 2025, at 13:15, Takeshi Nishimura wrote: > On Sat, Jan 4, 2025 at 4:40 PM Benjamin Coddington <bcodding@xxxxxxxxxx> wrote: >> >> On 3 Jan 2025, at 18:07, Takeshi Nishimura wrote: >> >>> On Thu, Jan 2, 2025 at 4:38 PM Benjamin Coddington <bcodding@xxxxxxxxxx> wrote: >>>> >>>> On 26 Dec 2024, at 19:45, Takeshi Nishimura wrote: >>>> >>>>> Dear list, >>>>> >>>>> Is there a document which explains the structure of the Linux >>>>> NFSv4.1/4.2 client source code? >>>> >>>> No, I don't believe there is any such document. >>>> >>>>> And where can I find the code which negotiates between NFSv4.1 and >>>>> NFSv4.2 versions, and a potential NFSv4.3? >>>> >>>> For the client, that code is in the nfs-utils tree in the mount.nfs binary, >>>> source in utils/mount/stropts.c - look for "nfs_autonegotiate()". If the >>>> mount command does not specify exactly the minor version, then a mount is >>>> tried with decreasing minor versions. >>> >>> So mount.nfs adds vers=4.2, if that fails it retries with vers=4.1, vers=4.0? >>> >>> Where in the kernel is the minor version from the parsed vers=4.2 option used? >> >> Start looking around in fs/nfs/fs_context.c for "minorversion".. > > Thanks > > Another question about NFS 4.1 / 4.2 client implementation: Is the > NFSv4. minor version per session? Could a NFS client implemenation > send both NFSv4.1 and NFSv4.2 compound requests, if they are in > different NFS sessions? I think this question is less about the linux implementation, and more about the protocol. The minor version is actually part of the COMPOUND arguements (See RFC-8881). I do think a client could mix minor version COMPOUNDs on the same session, but I'm pretty sure the linux client doesn't do that (it doesn't change the minorversion depending on what it sends in the COMPOUND). I am often wrong, however - don't be surprised if someone corrects me here. :) In these matters of how the protocol works, often the best place to ask clarifying questions (if the RFCs are unclear) is the nfsv4.ietf.org mailing list. Ben
