9p: mounts: evaluate if we use 9p2000.[uL] or not

[grahamwhaley]

afaict, we are currently mounting 9p volumes as '9p', which gets us the base level '9p2000' mount type. There are two further extensions - the .u extension for better POSIX compat, and the .L extension for better Linux compat - we should check out if we really are on baseline 9p2000, and test out 9p2000.[uL] to see if they help with any of our 9p corner cases.

At the same time, we should re-visit #31 and evaluate how the msize 9p argument benefits or affects us.

[grahamwhaley]

An update on the 9p2000[.uL] then.
I used https://github.com/clearcontainers/osbuilder to run up images with the agent modified at https://github.com/clearcontainers/agent/blob/master/syscall.go#L110 to add in the options of version=xxx as appropriate.
I then used https://github.com/pjd/pjdfstest to run POSIX tests (v.similar to our use at https://github.com/clearcontainers/tests/tree/master/conformance/posixfs, but the github code base looks more upto date and maintained than the sourceforge one).

Running on our default 9p mount, I got 90 (out of 8789) tests fail.

Running on '9p2000.L` I got 88 tests - we pass two of the symlink tests that we previously failed (and, iirc, symlinks is one of the things that the 'L' version improved).

Running on '9p2000.u' hangs up some way through the test suite. I've not debugged it, as if we were going to move then ideally we'd move to .L.

Just for reference, I ran the githug code base under a runc with overlay2 as the graph driver, and all the tests passed.

From that then, maybe we should move to .L, for the small improvement. Before we do that, I'll do some performance tests to see if there is any noticeable difference (I suspect not, but we'll see), and also investigate the msize option more.

[sboeuf]

Well at least it's nice that L option brings in some fixes. And we should move to this option if you cannot see any performances drop !

[grahamwhaley]

I ran a blogbench test (which I'll be adding to the tests repo and clearcontainers/tests#880 soon) in order to get a peek at multi file read/write data as well as just raw storage bandwidth. Results:

9p                                                                                                       
+------------------+----------+----------+----------+---------+-------+-------+                          
|       NAME       |   MEAN   |   MAX    |   MIN    |   SD    |  COV  | ITERS |                          
+------------------+----------+----------+----------+---------+-------+-------+                          
| blogbench-reads  | 8244.900 | 8726.000 | 7538.000 | 405.947 | 4.924 |    10 |                          
| blogbench-writes |  154.800 |  162.000 |  147.000 |   4.976 | 3.214 |    10 |                          
+------------------+----------+----------+----------+---------+-------+-------+                          
L                                                                                                        
+------------------+----------+----------+----------+---------+-------+-------+                          
|       NAME       |   MEAN   |   MAX    |   MIN    |   SD    |  COV  | ITERS |                          
+------------------+----------+----------+----------+---------+-------+-------+                          
| blogbench-reads  | 8099.300 | 9076.000 | 7678.000 | 445.346 | 5.499 |    10 |                          
| blogbench-writes |  156.900 |  166.000 |  150.000 |   4.908 | 3.128 |    10 |                          
+------------------+----------+----------+----------+---------+-------+-------+ 

Results look within expected noise and show no major regressions to me. I'll add updating our mounts to 9p2000.L to my todo list...

[sboeuf]

@grahamwhaley if you have a lot on your plate, please open an issue and someone else will take care of that ;)

[grahamwhaley]

opened #214. We could in theory close this one now.