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. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-M613a9a70317e111f7128e8d5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
