From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "Douglas A. Gwyn" Message-ID: <3A820C11.5A948B90@arl.army.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20010207152343.C1B91199E1@mail.cse.psu.edu>, <200102080119.UAA03525@augusta.math.psu.edu> Subject: Re: [9fans] 9p2k, fsync Date: Thu, 8 Feb 2001 09:43:21 +0000 Topicbox-Message-UUID: 5e31eb1c-eac9-11e9-9e20-41e7f4b1d025 Dan Cross wrote: > Multics had this problem; no synchronization primitives for segments. > It was impossible to build a database on it for many years (maybe they > fixed it eventually; I don't know), because one couldn't guarantee > serialization of transactions on persistent media. It would be a shame > to send Plan 9 down the same road for the exact same reason. I think that all that is required is consistency. The server is the right place to enforce that, and I'd suggest making it an explicit requirement. How about this: To ensure that a 9P2k message has been integrated into the server state, just wait for an ack for the message, or if it is one-way, send some innocuous request and wait for it to return data. Getting the feedback from the server guarantees that the server (which is responsible for maintaining consistency) has successfully processed the previous request. Of course, if the service does a lousy job you have reason to demand an improved server. I once encountered a disk drive that apparently wrote data to disk successfully, except it didn't modify the sectors that it was supposed to have written. In the face of such phenomena it is pointless to insist on absolute guarantees of synchronization. Good design calls for such secondary matters to be handled as close to the source of the problem as possible, rather than intruding such low-level considerations into higher logical levels. If something does happen at a lower level that necessarily affects things at a higher level, then so be it, but if it couldn't be solved down there it can't be solved up here either, and up here dealing with it distracts from the more strategic concerns. (For similar reasons I am a fan of nested exception handling instead of functions returning failure codes, but that's another thread.)