|
|
researchv8 Dan Cross
/tmp/xxx looks like a 1048576 byte file, but it is all holes except for the last block. :;time cat /tmp/xxx > /dev/null 0.1u 2.4s 3r cat /tmp/xxx :;time cat /n/debug/tmp/xxx > /dev/null 0.2u 20.0s 66r cat /n/debug/tmp/xxx Thus the netfs without disk delay is running at 15887 bytes per second. If the file is buffered in the server there is no noticable change. Thus the slow rate is in the protocol. ws%time cat /n/seki/tmp/__2148 > /dev/null #totally buffered in server 0.1u 21.2s 52r cat /n/seki/tmp/__2148 ws%time cat /n/seki/tmp/xxx > /dev/null #hole file, no buffering in server 0.0u 20.8s 53r cat /n/seki/tmp/xxx ws%time cat /n/seki/tmp/xxx > /dev/null #no holes either 0.0u 20.8s 53r cat /n/seki/tmp/xxx the netfs runs at bout 19784 bytes per second, with no perceptible effect of disk or buffering at host end. 1000 local fstats take about 11 seconds of system time, while 1000 getuids take about 2.7 seconds. 1000 remote fstats of /n/debug take 33 seconds of real time, about 10 milliseconds a message. Now if the server and setup are connected through a pipe, instead of the network, catting the file with holes: :;time cat m/tmp/9489 > /dev/null 0.1u 5.1s 12r cat m/tmp/9489 without holes: :;:;time cat m/tmp/x > /dev/null 0.1u 5.2s 12r cat m/tmp/x
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.