Thanks for your reply Ron. At least now I know that Tflush and Tversion in the middle of a running session can really be beasts and this wasn't only my imagination.
I'm writing three filesystems for my applications needs. For the first the whole tflush, tversion (which is far more dangerous than tflush for a backend server) isn't important because this is a read-only bootfilesystem which replaces the boot infrastructure (9fat, nvram, kfs/fossil/paqfs/...) with a single partition (without the need to search for plan9.ini, boot, the kernel aso). The second filesystem is my fileserver/database front-end which resides on a host in the internet. And 9p is poison for this task (as defined in man 5 section). The current 9p protocol resembles in my opinion some kind of a transaction system while lacking the most important message "commit". Tversion starts a transaction (called session in the manual) and Tflush and Tversion are aquivalents to a "rollback" while there is no way to "commit" changes to the server. If the client loses his connection a real world backend would have to rollback all changes. Also Tflush, Tversion would make it necessary to store all changes temporarily while there the only message that represents a semi-commit would be Tclunk. The fileservers used on plan9 aren't affected by the lack of a session commit cause kfs as well as fossil are journaling filesystems (at least operatable in this way) but 9p enpowers the client while endangering the server. I rewrote fcall, lib9p to understand the 9p protocol and decided to write a front-end for my hosted fileserver(database+filesystem) based on a tcp protocol. While a plan9 client establishes a connection with sending Tversion I send a "begin" to the main server. After each Tclunk I send "commit" and "begin" and after a Tflush or Tversion I send a "rollback" and a "begin" to the Server for Tflush an immediate Rflush to the client. I'm not happy with this cause Tclunk as the marker for "commit" and "begin" isn't right but thats the way I did it now. If I would have the choice I would change 9p : Tversion <==> Tversion (handshake for protocol version and messagesize without rollback functionality) <==> Tbegin (Starting a transaction/session) Tflush <==> Trollback (only a renaming to make clear what is meant) Tcommit <==> (End the transaction and make the changes permanent) While at it I would also reduce the amount of information a client can aquire by a tstat or write with a twstat. I would also make ntags 64 bit or at least 32 bit. To summarize : I think the lack of a "commit" while starting a session with Tversion rolling it back with Tflush or Tversion has caused me some headache. Ron, thanks for replying. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-M8716c512cdfc3a448b17a9ca Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
