Re: [9fans] A few questions about 9p

["ibrahim via 9fans" <9fans@9fans.net>]

[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2757 bytes --]