Tflush is harder than it looks, given that it is part of a giant race condition. Will you get the R for the message you are flushing right after you send Tflush? What happens at the server? It's fun.

Perhaps one of the biggest uses of 9p, globally, was google's gvisor, which runs an unimaginably large (to me anyway :-) amount of compute in Google Cloud. gvisor: https://gvisor.dev/docs/, Comparison here: https://www.scitepress.org/Papers/2021/104405/104405.pdf

I suspect more bytes moved through 9p on gvisor in a day than moved on all other platforms since 2000. All I can say is, it's a lot.

gvisor used to use 9p (my fault :-) and, although we started with Andrey and Lucho's go9p, at some point it was replaced by Chris Koch's implementation. It's quite good.

You can see how Chris handled Tflush here: https://github.com/hugelgupf/p9/blob/main/p9/handlers.go#L104

I'd argue that this may be the most real-world-tested Tflush handler you'll see. I have seen Tflush handlers that just return, having done nothing, and it's possible that in many cases, that's good enough. But Chris's code is VERY heavily tested with real workloads.

I also know, as I saw it many times, that the Plan 9 kernel Tflush could at times get extremely confused. When we ported it to Akaros, we even saw cases where Tflush would run out of control and exhaust the XID space, sending flush after flush as fast as it could create them.

Finally, due to some issues with 9p that could not be fixed, the gvisor engineers created a new protocol, LISA, https://github.com/google/gvisor/tree/master/pkg/lisafs, worth reading.

HTH

ron

p.s. FYI, when we first started gvisor, we had it in mind that it could support Plan 9 binaries, and planned accordingly, but that was never tested.

On Mon, Oct 31, 2022 at 4:15 PM ibrahim via 9fans <9fans@9fans.net> wrote:

I have read the manuals and also searched for this question here without finding an answer (perhaps I missed it) :

1) question about flush :

Lets say there was a pending message with tag=1234 and the client of my server sent a flush message with a tag=1450. During the travel of the flush the server sent a response to the message tagged 1234 cause it finished.

The manual states that the client has to forget about the flush message as if never sent. Does that mean that message tagged with 1450 which is now ignored by the server won't be replied (no error reply and no success reply cause if the server would reply with rflush the client would take this as if the flush succeeded due to the manual page).

Can a client reuse a tag from an unanswered flush message immediatly (in the example tag 1450)

2) tversion

A client sends tversion while in the middle of a running session. Is it right to abort/ignore/close/flush all possibly pending messages from the prior session ?

The next question is regarding msize[4] in tversion. How should a server respond when msize suggested from the client is to small like msize-IOHDRSIZE< one min_stat_size ?

Thanks in advance ;)