Rob Landley (landley) wrote,
Rob Landley
landley

dullboy

I was writing up a longish post about tracing the flow of control through the nfs and sunrpc code when my laptop battery died and I lost all my open windows, including some state I apparently hadn't saved in a while. (Oops.) On the other hand, the expedition/writeup was turning into one of those "Dr. Livingston I. Presume was Dr. Presume's full name" safaris where you never make it back to your point of origin and instead get lost in the jungle.

So instead I stepped back and hijacked the test code from the getaddrinfo man page, turning it into a quick and dirty UDP intercept and forward daemon, which lets me monitor the darn wire protocol, like so:

Forward 40 bytes from 192.168.2.108:35003 to 9999
Return 24 bytes to 192.168.2.108:35003
Forward 108 bytes from 192.168.2.108:35003 to 9999
Return 80 bytes to 192.168.2.108:35003
Forward 40 bytes from 192.168.2.108:50209 to 9999
Return 24 bytes to 192.168.2.108:50209
Forward 40 bytes from 192.168.2.108:50209 to 9999
Return 24 bytes to 192.168.2.108:50209
Forward 112 bytes from 192.168.2.108:50209 to 9999
Return 164 bytes to 192.168.2.108:50209
Forward 112 bytes from 192.168.2.108:50209 to 9999
Return 140 bytes to 192.168.2.108:50209
Forward 112 bytes from 192.168.2.108:50209 to 9999
Return 164 bytes to 192.168.2.108:50209
Forward 116 bytes from 192.168.2.108:50209 to 9999
Return 120 bytes to 192.168.2.108:50209
Forward 112 bytes from 192.168.2.108:50209 to 9999
Return 112 bytes to 192.168.2.108:50209
Forward 136 bytes from 192.168.2.108:50209 to 9999
Return 32 bytes to 192.168.2.108:50209
Forward 132 bytes from 192.168.2.108:50209 to 9999
Return 328 bytes to 192.168.2.108:50209


That is the complete network traffic for mounting an NFSv3 share, listing its contents, and unmounting again. The actual "ls" is just the last pair of packets, everything before that is the mount. (Note that umount creates no actual network traffic, due to the designers being completely insane.) Oh, and mountd and nfsd are currently on the same port because otherwise I'd have to run two copies of the inteceptor and interleave their log output, but I suspect the move from port 35003 to port 50209 was the handoff there.

If all I had to deal with was the wire protocol, and not the fact that NFS _REIMPLEMENTS_HALF_THE_VFS_LAYER_ this would be merely unpleasant. As it is, my plan currently looks like this:

1) Track down every single packet in that series and get it to happen in the right network context.

2) Track down every single unnecessary optimization NFS is doing that would interfere with running that in two containers mounting from the same server (like merging superblocks and stuffing all non-idempodent transactions into a common cache) and either disable it (preferred) or glue network namespace information to it (if I can't disable it for non-init network namespaces). This involves working out proper test cases.

3) Add more tests like "df nfsdir" and "cat nfsdir/file".

4) Mount the sucker rw and make writing work. (touch, mkdir, mv...)

5) Scream a lot.
Tags: dullboy
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 0 comments