It's a network protocol as far as everything from Plan9 was designed to be able to operate over the network in the late 90s sense of " the network is the computer". The local file system of Plan 9 though is exposed locally through 9p
Yeah, and that's one of the reasons plan9 was dogshit and never amounted to anything. "Everything is a file" is bad enough, "Everything is a file which might be 'transparently' across a network" is insane.
Classic blocking I/O is the problem, not network transparency. If you don't want files to be transparent through latency/throughput boundaries, then you should also disable the VFS cache.
Filesystem cache may make latency unpredictable, but it won't make open() unexpectedly fail with ECONNREFUSED. Most programs barely handle ENOENT, let alone EINTR.
Also, how do you do async fstat and mkdir in Linux? I don't see it in manpages.
AFAIK Plan9 answers to that was to not implement POSIX interfaces, and instead all I/O looked like RPC calls. This is generally a good design idea, but it's hard to sell an OS where all existing software will have to be rewritten for.
> Also, how do you do async fstat and mkdir in Linux? I don't see it in manpages.
io_uring. and a virtual filesystem may have to serve multiple concurrent requests from several threads. so even if individual IO calls are blocking in the aggregate they still have to be interleaved.
Conceptually it's possible: async fstat sets pending read, then epoll could return read flag when it completes, after that fstat completes without delay.
