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 16284 invoked from network); 5 Nov 2022 01:32:46 -0000 Received: from tb-ob0.topicbox.com (64.147.108.117) by inbox.vuxu.org with ESMTPUTF8; 5 Nov 2022 01:32:46 -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 81B3324121 for ; Fri, 4 Nov 2022 21:32:43 -0400 (EDT) (envelope-from bounce.mM8716c512cdfc3a448b17a9ca.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx1.topicbox.com (Postfix, from userid 1132) id 7C57630AE13; Fri, 4 Nov 2022 21:32:43 -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=1667611963; x=1667698363; bh=h7MOxjO0rTE9aihBOBn2rnmQX XoM1SyC/butwWQ9TSE=; b=NN1+JeIzPlPb2bD0r+ubgZV5jp6Mwx9rYo8zwVGQg 3hlVKJl/iWsdpRSS5Ml60JBzgMMMgtE+XeTbzEtwB2DNtu/fcYgkPYnxliozgh4B rm1DYQMJK+dG/+n0FwZPoXKp8w36THTie33iEE7iDV5WpUpyM941Dt7W8LqPZylk wc= To: 9fans <9fans@9fans.net> Subject: Re: [9fans] A few questions about 9p Message-Id: <16676119560.D17AdC.921072@composer.9fans.topicbox.com> In-Reply-To: References: <16672580590.81C97dEDC.85252@composer.9fans.topicbox.com> Date: Fri, 4 Nov 2022 21:32:36 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=16676119561.fAafC26.921072 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: baa4c784-5ca9-11ed-a078-1049292d11b0 Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UMDRlMTFmZTE0NzM5ZGE2OC1NODcxNmM1MTJjZGZjM2E0NDhiMTdh?= =?UTF-8?B?OWNhPg==?= 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:M8716c512cdfc3a448b17a9ca:1:3QqR1iTaa6wz5ZfFHSdrWXWPZEM4qou3arx8mkqSorI --16676119561.fAafC26.921072 Date: Fri, 4 Nov 2022 21:32:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for your reply Ron.=20 At least now I know that Tflush and Tversion in the middle of a running ses= sion can really be beasts and this wasn't only my imagination.=20 I'm writing three filesystems for my applications needs. For the first the = whole tflush, tversion (which is far more dangerous than tflush for a backe= nd server) isn't important because this is a read-only bootfilesystem which= replaces the boot infrastructure (9fat, nvram, kfs/fossil/paqfs/...) with = a single partition (without the need to search for plan9.ini, boot, the ker= nel aso). The second filesystem is my fileserver/database front-end which resides on = a host in the internet. And 9p is poison for this task (as defined in man 5= section). The current 9p protocol resembles in my opinion some kind of a t= ransaction system while lacking the most important message "commit". Tversi= on starts a transaction (called session in the manual) and Tflush and Tvers= ion are aquivalents to a "rollback" while there is no way to "commit" chang= es to the server. If the client loses his connection a real world backend w= ould have to rollback all changes. Also Tflush, Tversion would make it nece= ssary to store all changes temporarily while there the only message that re= presents a semi-commit would be Tclunk.=20 The fileservers used on plan9 aren't affected by the lack of a session comm= it cause kfs as well as fossil are journaling filesystems (at least operata= ble in this way) but 9p enpowers the client while endangering the server. I rewrote fcall, lib9p to understand the 9p protocol and decided to write a= front-end for my hosted fileserver(database+filesystem) based on a tcp pro= tocol. While a plan9 client establishes a connection with sending Tversion = I send a "begin" to the main server. After each Tclunk I send "commit" and = "begin" and after a Tflush or Tversion I send a "rollback" and a "begin" to= the Server for Tflush an immediate Rflush to the client. I'm not happy wit= h this cause Tclunk as the marker for "commit" and "begin" isn't right but = thats the way I did it now. If I would have the choice I would change 9p : Tversion=20 <=3D=3D> Tversion (handshake for protocol version and messagesize without r= ollback functionality) <=3D=3D> Tbegin (Starting a transaction/session) Tflush <=3D=3D> Trollback (only a renaming to make clear what is meant) Tcommit <=3D=3D> (End the transaction and make the changes permanent) While at it I would also reduce the amount of information a client can aqui= re by a tstat or write with a twstat. I would also make ntags 64 bit or at = least 32 bit.=20 To summarize : I think the lack of a "commit" while starting a session with= Tversion rolling it back with Tflush or Tversion has caused me some headac= he. Ron, thanks for replying. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-M8716c= 512cdfc3a448b17a9ca Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --16676119561.fAafC26.921072 Date: Fri, 4 Nov 2022 21:32:36 -0400 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your reply Ron.
At least now I know that Tflush and Tversion in the middle o= f a running session can really be beasts and this wasn't only my imagin= ation.

I'm writing three filesystems = for my applications needs. For the first the whole tflush, tversion (which = is far more dangerous than tflush for a backend server) isn't important= because this is a read-only bootfilesystem which replaces the boot infrast= ructure (9fat, nvram, kfs/fossil/paqfs/...) with a single partition (withou= t the need to search for plan9.ini, boot, the kernel aso).
=
The second filesystem is my fileserver/database front-end = which resides on a host in the internet. And 9p is poison for this task (as= defined in man 5 section). The current 9p protocol resembles in my opinion= some kind of a transaction system while lacking the most important message= "commit". Tversion starts a transaction (called session in the m= anual) and Tflush and Tversion are aquivalents to a "rollback" wh= ile there is no way to "commit" changes to the server. If the cli= ent loses his connection a real world backend would have to rollback all ch= anges. Also Tflush, Tversion would make it necessary to store all changes t= emporarily while there the only message that represents a semi-commit would= be Tclunk.

The fileservers used on plan9= aren't affected by the lack of a session commit cause kfs as well as f= ossil are journaling filesystems (at least operatable in this way) but 9p e= npowers the client while endangering the server.

I rewrote fcall, lib9p to understand the 9p protocol and decided to = write a front-end for my hosted fileserver(database+filesystem) based on a = tcp protocol. While a plan9 client establishes a connection with sending Tv= ersion I send a "begin" to the main server. After each Tclunk I s= end "commit" and "begin" and after a Tflush or Tversion= I send a "rollback" and a "begin" to the Server for Tf= lush an immediate Rflush to the client. I'm not happy with this cause T= clunk as the marker for "commit" and "begin" isn't = right but thats the way I did it now.

If I= would have the choice I would change 9p :

Tversion
<=3D=3D> Tversion (handshake for protocol = version and messagesize without rollback functionality)
<= ;=3D=3D> Tbegin (Starting a transaction/session)

<= /div>
Tflush
<=3D=3D> Trollback (only a renaming = to make clear what is meant)

Tcommit
=
<=3D=3D> (End the transaction and make the changes permane= nt)

While at it I would also reduce the am= ount of information a client can aquire by a tstat or write with a twstat. = I would also make ntags 64 bit or at least 32 bit.

<= /div>
To summarize : I think the lack of a "commit" while sta= rting a session with Tversion rolling it back with Tflush or Tversion has c= aused me some headache.

Ron, thanks for re= plying.


= --16676119561.fAafC26.921072--