Quoth ibrahim via 9fans <9fans@9fans.net>: > 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 handler you'll > > see. I have seen Tflush handlers that just return, having done nothing, and > > it's possible that in many cases, that's good enough. But Chris'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. > > 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 Tflush would run out of control and exhaust the XID space, > > sending flush after 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 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." > > 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 responded afterwards all the other Tflushes arrive and can't > be responded
This situation is impossible -- you can always respond to a Tflush. Repeated tflushes for the same tag may simply be coalesced into one response. > so all ntags used by Tflush messages after the first can't be used 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 order after the > first Tflush got processed. Yes, it responds with an Rflush. > 1) All ntags used for Tflush after the first are considered open. 2) A server > can't even hint with an error for a Tflush with an inactive oldtag. A flush means "I don't care about the response any more". For example, cancelling the next mouse read before the mouse moves, because the graphical program is exiting. > 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). As can any other message; this is fine, you don't want 65535 outstanding messages anwyays, most of the time. > > If 9P2000 won't change at least some changes to the effects of Tflush 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 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. Flushes are fired on interrupt, because the result of an in-flight read or write is no longer needed; Why would you want an alarm firing to close the file you're reading? that makes no sense. > Those two changes would build a "mini-transaction" enviroment : > > Topen/Tcreate > ==> starts a file transaction > > Tflush > ==> interrupt file operation for fid associated with oldtag, clunk the fid > with a rollback > > Tclunk > ==> commit changes to the file > > Tversion > ==> rollback all open changes not commited in the previous session. 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. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-Mcfef687d4d59cc5bad0576f2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
