Slow cp, support for 9P2000.s

[Romano <unobe@cpan.org>]

On my local wireless network at home between my work laptop and my rpi 4, I tested using 'cp' while in drawterm.  I ran drawterm -G on my rpi, and used srvfs to export its file system. I ran drawterm on my work laptop, and mounted the exported filesystem as /n/pi.  I then timed a 20MB file from /mnt/term/root/ on my work laptop to the /n/pi: 0.20u 0.82s 70.14r. 70s is atrociously slow for a local copy when compared to http or scp, so I decided to look to see if this was known and if any work had been done on this problem for 9p.  I came across John Floren's thesis from 2010[1] and his testing showed that increased latency over 9p significantly increased the time files took to transfer. He also shows modifications to 'cp' and 'exportfs' to allow for streams to make 9p have similar speeds as http. 

So considering Floren's research, I then decided to look at my latency on my local network, and sure enough, I'm getting the following ping results (for 144 packets transmitted, with 1 packet lost): round-trip min/avg/max/stddev = 2.273/15.264/497.869/44.018 ms . With an average latency of 15ms, the time it took for  20MB file to transfer over 9p roughly matches Floren's tests.

I think that modifying 'cp' and 'exportfs' would resolve this problem and will look at patching it per Floren's thesis to confirm.  Would modifying 'cp' and 'exportfs' to allow for streams be something others would be interested in? Or has this already been discussed and the stream solution been found wanting for some technical reason? The protocol, as mentioned in the paper, is called 9P2000.s. I don't see that flavor listed here: http://9p.cat-v.org/implementations

[1] https://pdfs.semanticscholar.org/9b47/22e251df61b4abbe0da61720e57ac7b62f61.pdf