Thank you for your clarifications Ori. From the perspective of kernel filesystems what you wrote made things clear. But one question remains regarding tflush and user fileservers :
On Saturday, 5 November 2022, at 5:31 AM, ori wrote:
This situation is impossible -- you can always respond to a Tflush. Repeated tflushes for the same tag may
simply be coalesced into one response.
tflush is also used to interrupt pending requests in user-file-systems. And there such a situation can happen where you can't respond to a Tflush. The server already processed the message for noldtag and sent its reply. Now you can't reply to a tflush with rflush cause that would mean the Tflush was successful and you can't answer with Rerror cause the rule says that Rerror is not allowed as a response to Tflush messages. Am I right regarding this situation or is this a misunderstanding.
On Saturday, 5 November 2022, at 5:31 AM, ori wrote:
how would this work for file systems like kbdfs, /net, etc? your proposal doesn't work for most of the file systems shipped with plan 9.
You are right I only looked at the problems from the perspective of the user-fileservers I am developing right now. And so I tried to understand the possible impact of tflush for data-integrity.
After your response I'll use this strategy in my user-fileservers :
1) Repond to Tflush right away with Rflush
2) Revert all changes to the file/directory ==> A full rollback
3) Invalidate the fid and reply with Rerror on the next message where this fid is used.
4) Make changes permanent only after a Tclunk for a valid fid.
5) Document this behavior.