From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22708 invoked from network); 5 Nov 2022 06:30:57 -0000 Received: from tb-ob1.topicbox.com (64.147.108.173) by inbox.vuxu.org with ESMTPUTF8; 5 Nov 2022 06:30:57 -0000 Received: from tb-mx0.topicbox.com (tb-mx0.nyi.icgroup.com [10.90.30.73]) by tb-ob1.topicbox.com (Postfix) with ESMTP id E5EF43596E for ; Sat, 5 Nov 2022 02:30:55 -0400 (EDT) (envelope-from bounce.mM613a9a70317e111f7128e8d5.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx0.topicbox.com (Postfix, from userid 1132) id DC1232BFE13; Sat, 5 Nov 2022 02:30:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h=to:subject :message-id:in-reply-to:references:date:mime-version :content-type:content-transfer-encoding:list-help:list-id :list-post:list-subscribe:reply-to:from:list-unsubscribe; s= dkim-1; t=1667629855; x=1667716255; bh=0LtrQDKjKlOix0fPG6OWty3Ul 65fmuTYRexwL1bVY58=; b=ack/qTbbB3ILEpl2V/oWofVfcbpXfIaov2gsDPj+5 GmBDpSt7p8pYvkJMzg21H+Nz8nqME0v1Kr385pqnplgPV4KbpBvVqbIPM+jeCdwA IUT1JpOifGKkAkDov8JCj++GPsy9s4NVomv8o9yFmtjYnw3b0liCyzhqzG90W6hZ 7E= To: 9fans <9fans@9fans.net> Subject: Re: [9fans] A few questions about 9p Message-Id: <16676298510.a96B.653661@composer.9fans.topicbox.com> In-Reply-To: References: Date: Sat, 5 Nov 2022 02:30:51 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=16676298511.bF3e71c25.653661 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 64a541b8-5cd3-11ed-90ad-1049292d11b0 Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UMDRlMTFmZTE0NzM5ZGE2OC1NNjEzYTlhNzAzMTdlMTExZjcxMjhl?= =?UTF-8?B?OGQ1Pg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> From: "ibrahim via 9fans" <9fans@9fans.net> List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:M613a9a70317e111f7128e8d5:1:Ey7k13xDk1z7_eE8lggT3zNT1wufx-XgnnX3j-uDBbQ --16676298511.bF3e71c25.653661 Date: Sat, 5 Nov 2022 02:30:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you for your clarifications Ori. From the perspective of kernel files= ystems 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. Repea= ted 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 y= ou 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 Rerro= r is not allowed as a response to Tflush messages. Am I right regarding thi= s situation or is this a misunderstanding.=20 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 use= r-fileservers I am developing right now. And so I tried to understand the p= ossible impact of tflush for data-integrity.=20 After your response I'll use this strategy in my user-fileservers : 1) Repond to Tflush right away with Rflush=20 2) Revert all changes to the file/directory =3D=3D> 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.=20 5) Document this behavior. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-M613a9= a70317e111f7128e8d5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --16676298511.bF3e71c25.653661 Date: Sat, 5 Nov 2022 02:30:51 -0400 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for your clarifications Ori. From th= e perspective of kernel filesystems what you wrote made things clear. But o= ne question remains regarding tflush and user fileservers :

On Saturday, 5 November 2022, at 5:31 AM, ori wrote:
This situation is impossible -- you can al= ways respond to a Tflush. Repeated tflushes for the same tag may simply be coalesced into one response.

<= div>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 Tfl= ush. The server already processed the message for noldtag and sent its repl= y. Now you can't reply to a tflush with rflush cause that would mean th= e 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 rig= ht regarding this situation or is this a misunderstanding.


On Saturday, 5 November 2022, at 5:31 AM= , ori wrote:
how would this work for f= ile 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 t= he user-fileservers I am developing right now. And so I tried to understand= the possible impact of tflush for data-integrity.

<= /div>
After your response I'll use this strategy in my user-fileser= vers :

1) Repond to Tflush right away with= Rflush
2) Revert all changes to the file/directory =3D=3D= > A full rollback
3) Invalidate the fid and reply with R= error on the next message where this fid is used.
4) Make c= hanges permanent only after a Tclunk for a valid fid.
5) D= ocument this behavior.


= --16676298511.bF3e71c25.653661--