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, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4523 invoked from network); 5 Nov 2022 04:10:14 -0000 Received: from tb-ob0.topicbox.com (64.147.108.117) by inbox.vuxu.org with ESMTPUTF8; 5 Nov 2022 04:10:14 -0000 Received: from tb-mx1.topicbox.com (tb-mx1.nyi.icgroup.com [10.90.30.61]) by tb-ob0.topicbox.com (Postfix) with ESMTP id 3BC9924FD4 for ; Sat, 5 Nov 2022 00:10:13 -0400 (EDT) (envelope-from bounce.mMd0bfd4f48352cded476092f3.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx1.topicbox.com (Postfix, from userid 1132) id 333DD30D5A2; Sat, 5 Nov 2022 00:10:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h=to:subject :message-id:references:in-reply-to: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=1667621413; x=1667707813; bh=xHZHLeGrSkmFknye63tl8q56e aty4f0cf7JFRBgIawM=; b=cTnJwSDzmP1AAmRYwxdLXGr8Z3T/3OvOsic1B2sCB gkNrAnWj9btqApTL2NrnsiGizBSwRjnwCIFq2HyYEs5zHbXRA8esy0V2CWi9603X Bi/dqLAdfdxLpaUMzLdQRahm2uNMAv3t/YmCy9KfsKgluY1waWaaNF87vikGZzDe OI= To: 9fans <9fans@9fans.net> Subject: Re: [9fans] A few questions about 9p Message-Id: <16676214030.bB1Ae.26874@composer.9fans.topicbox.com> References: <16672580590.81C97dEDC.85252@composer.9fans.topicbox.com> In-Reply-To: Date: Sat, 5 Nov 2022 00:10:03 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=16676214031.2AFEe.26874 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: b99fcfa8-5cbf-11ed-9225-f4e89134e1fa Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UMDRlMTFmZTE0NzM5ZGE2OC1NZDBiZmQ0ZjQ4MzUyY2RlZDQ3NjA5?= =?UTF-8?B?MmYzPg==?= 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:Md0bfd4f48352cded476092f3:1:LWbY8FViqLgTq4_dIRusdKD7C-c64FqziIW5tf68-jM --16676214031.2AFEe.26874 Date: Sat, 5 Nov 2022 00:10:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, 5 November 2022, at 12:41 AM, ron minnich wrote: > I'd argue that this may be the most real-world-tested Tflush=C2=A0handler= you'll see. I have seen Tflush=C2=A0handlers that just return, having done= nothing, and it's possible that in many cases, that's good enough. But Chr= is's code is VERY heavily tested with real workloads. I'm not surprised. Interrupting hardware access for a few kB and risking to= damage the filesystem wouldn't be wise.=20 On Saturday, 5 November 2022, at 12:41 AM, ron minnich wrote: > I also know, as I saw it many times, that the Plan 9 kernel Tflush=C2=A0c= ould at times get extremely confused. When we ported it to Akaros, we even = saw cases where Tflush would run out of control and exhaust the XID space, = sending flush after flush as fast as it could create them. >=20 The rule :=20 "Should multiple Tflushes be received for a pending request, they must be a= nswered in order. A Rflush for any of the multiple Tflushes implies an answ= er for all previous ones. Therefore, should a server receive a request and = then multiple flushes for that request, it need respond only to the last fl= ush." and : "A Tflush can never be responded to by an Rerror message." should lead to a dead lock in this situation. Lets say the first Tflush arr= ived and got responded afterwards all the other Tflushes arrive and can't b= e responded so all ntags used by Tflush messages after the first can't be u= sed by the client cause there are pending unanswered requests by the client= . The server can never respond with an Rerror to a Tflush arriving out of o= rder after the first Tflush got processed. 1) All ntags used for Tflush aft= er the first are considered open. 2) A server can't even hint with an error= for a Tflush with an inactive oldtag. Rerror with "error : noldtag invalid= " would at least make the ntags reusable for the client. If the client code= is conforming to the rules in man(5) Tflush messages can burn all possible= ntag values (16 bit). If 9P2000 won't change at least some changes to the effects of Tflush and h= andling without breaking compatibility would be possible : 1) If a response to one of sent Tflush messages is made all Tflush messages= regarding oldtag are responded not only preceeding ones, cause only one Rf= lush or only one response to the oldtag is allowed by the server. more important my suggestion : 2) Tflush also leads to a clunk of a fid. This lets the server decide if it= will keep the changes or revert them. Those two changes would build a "mini-transaction" enviroment : Topen/Tcreate =3D=3D> starts a file transaction Tflush =3D=3D> interrupt file operation for fid associated with oldtag, clunk the = fid with a rollback Tclunk =3D=3D> commit changes to the file Tversion =3D=3D> rollback all open changes not commited in the previous session. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-Md0bfd= 4f48352cded476092f3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --16676214031.2AFEe.26874 Date: Sat, 5 Nov 2022 00:10:03 -0400 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, 5 November 2022, at 12:41 AM, ron= minnich wrote:
=
I'd argue that this may be the most real-world-tested Tflush&= nbsp;handler you'll see. I have seen Tflush handlers that just ret= urn, having done nothing, and it's possible that in many cases, that= 9;s good enough. But Chris's code is VERY heavily tested with real work= loads.

I= 9;m not surprised. Interrupting hardware access for a few kB and risking to= damage the filesystem wouldn't be wise.

<= div>On Saturday, 5 November 2022, at 12:41 AM, ron minnich wrote:
I also know, as= I saw it many times, that the Plan 9 kernel Tflush could at times get= extremely confused. When we ported it to Akaros, we even saw cases where T= flush would run out of control and exhaust the XID space, sending flush aft= er flush as fast as it could create them.


The rule :

"Should multiple Tflushes be received for a pending = request, they must be answered in order. A Rflush for any of the multiple T= flushes implies an answer for all previous ones. Therefore, should a server= receive a request and then multiple flushes for that request, it need resp= ond only to the last flush."

and :

"A Tflush can never be responded to by = an Rerror message."

should lead to a = dead lock in this situation. Lets say the first Tflush arrived and got resp= onded afterwards all the other Tflushes arrive and can't be responded s= o all ntags used by Tflush messages after the first can't be used by th= e client cause there are pending unanswered requests by the client. The ser= ver can never respond with an Rerror to a Tflush arriving out of order afte= r the first Tflush got processed. 1) All ntags used for Tflush after the fi= rst are considered open. 2) A server can't even hint with an error for = a Tflush with an inactive oldtag. Rerror with "error : noldtag invalid= " would at least make the ntags reusable for the client. If the client= code is conforming to the rules in man(5) Tflush messages can burn all pos= sible ntag values (16 bit).


If 9P2000 won't change at least some changes to the effects of Tflus= h and handling without breaking compatibility would be possible :

1) If a response to one of sent Tflush messages is = made all Tflush messages regarding oldtag are responded not only preceeding= ones, cause only one Rflush or only one response to the oldtag is allowed = by the server.

more important my suggestio= n :

2) Tflush also leads to a clunk of a f= id. This lets the server decide if it will keep the changes or revert them.=

Those two changes would build a "min= i-transaction" enviroment :

Topen/Tcr= eate
=3D=3D> starts a file transaction
<= br />
Tflush
=3D=3D> interrupt file operation = for fid associated with oldtag, clunk the fid with a rollback

Tclunk
=3D=3D> commit changes to the= file

Tversion
=3D=3D> = rollback all open changes not commited in the previous session.
=




= --16676214031.2AFEe.26874--