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 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. 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. 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 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. 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. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-Md0bfd4f48352cded476092f3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
