9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "ibrahim via 9fans" <9fans@9fans.net>
To: 9fans <9fans@9fans.net>
Subject: Re: [9fans] A few questions about 9p
Date: Sat, 5 Nov 2022 11:50:30 -0400	[thread overview]
Message-ID: <16676634300.d2cE.77602@composer.9fans.topicbox.com> (raw)
In-Reply-To: <31E3D99136B73F9319EED5F9385942DA@eigenstate.org>

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

Thanks for your answer.

On Saturday, 5 November 2022, at 3:09 PM, ori wrote:
> The Tflush was successful: The Rflush does not indicate that a message was
cancelled, tit indicates that the server is no longer processing the request.

After your answer an read the manual pages a few times again and now I understand what to do :

1) All Tflush messages get a Rflush reply. If more than one Tflush arrives answering the last one means responding to all of them, like the manual states here :

"A Rflush for any of the multiple Tflushes implies an answer 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 flush."

2)Even when oldtag doesn't represent an active message Tflush gets a Rflush response. 

3) The only indicator for the client if his Tflush didn't interrupt (!!!) an active message cycle is (manual page) :

If a response to the flushed request is received before the Rflush, the client must honor the response as if it had not been flushed, since the completed request may signify a state change in the server. For instance, Tcreate may have created a file and Twalk may have allocated a fid. If no response is received before the Rflush, the flushed transaction is considered to have been canceled, and should be treated as though it had never been sent.

interpreted as : 

a) Server replies to oldtag before sending Rflush ==> indicates oldtag wasn't interrupted
b) Server sends Rflush before responding to oldtag ==> indicates oldtag-message was interrupted

4) Its legal that a client sends Tflush messages with an invalid oldtag for which it can expect an Rflush as response never an Rerror (manual) :

The server should answer the flush message immediately. If it recognizes oldtag as the tag of a pending transaction, it should abort any pending response and discard that tag. In either case, it should respond with an Rflush echoing the tag (not oldtag) of the Tflush message. A Tflush can never be responded to by an Rerror message.


Now my interpretation of Tflush and Rflush quite changed :

It seems that Tflush has at least two functions : 

(1) Interrupt a running message, while the probability to interrupt a running message is very small. 
(2) Polling the fileserver and guessing how it is implemented. A server with a simple sequential message processiong won't be able to respond to a Tflush by Rflush before responding to oldtag. A server which only replies to the n-th Tflush would be lagging and uses a message queue.

Consequences for my implementation :

1) Its not an error if Tflush uses an invalid oldtag even using the ntag of Tflush as oldtag would be valid.
2) Every Tflush gets an Rflush directly or indirectly (response to the last in a series is enough)
3) Tflush can be used/abused to measure the fileserver performance. Send a message and flush it to measure the time needed to process it. Send n messages and measure the response time-differences, aso.
4) Tflush is not related with transactions but has to be taken as a rollback if sent for an oldtag that interrupts a running write operation.


Thanks ori for your clear answers i got the right hints to check my understanding. And I had a misunderstanding regarding tflush till now so I needed to ask ;)

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-Ma697c45ddea03254971a41da
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

  reply	other threads:[~2022-11-05 15:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-31 23:14 ibrahim via 9fans
2022-11-04 23:41 ` ron minnich
2022-11-05  1:32   ` ibrahim via 9fans
2022-11-05  4:10   ` ibrahim via 9fans
2022-11-05  4:30     ` ori
2022-11-05  6:30       ` ibrahim via 9fans
2022-11-05 14:09         ` ori
2022-11-05 15:50           ` ibrahim via 9fans [this message]
     [not found] <CAHL7psHNZrbQuFRz5grmXgR686o2e+-SX=tW6yxnfNaduec5NQ@mail.gmail.com>
     [not found] ` <CAHL7psGPf3z56wjZGJsSVCeEzHBJgtbt17nL-UNA8kXKM-mkuw@mail.gmail.com>
     [not found]   ` <CAHL7psFTR7G1N069XoqYkuxJ_P0TYzmXAZ752wVa=9BAOX0CQg@mail.gmail.com>
     [not found]     ` <CAHL7psEUjdaV9LABzRrHn1TLftF+moxWV563-tvK+7VLviKhRg@mail.gmail.com>
2015-01-29  9:04       ` Giacomo Tesio
2015-01-29 10:07         ` Charles Forsyth
2015-01-29 14:36           ` erik quanstrom
2015-01-29 14:41           ` Giacomo Tesio
2015-01-29 14:52             ` erik quanstrom
2015-01-29 14:54             ` cinap_lenrek
2015-01-29 15:46               ` Giacomo Tesio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16676634300.d2cE.77602@composer.9fans.topicbox.com \
    --to=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).