On Tue Apr 21 10:34:34 EDT 2009, n...@lsub.org wrote: > Well, if you don't have flush, your server is going to keep a request > for each process that dies/aborts. If requests always complete quite > soon it's not a problem, AFAIK, but your server may be keeping the > request to reply when something happens. Also, there's the issue that > the flushed request may have allocated a fid or some other resource. > If you don't agree that the thing is flushed you get out of sync with the > client. > > What I mean is that as soon as you get concurrent requests you really > ned to implement flush. Again, AFAIK.
isn't the tag space per fid? a variation on the tagged queuing flush cache would be to force the client to make sure that reordered flush tags aren't a problem. it would not be very hard to ensure that tag "overlap" does not happen. if the problem with 9p is latency, then here's a decision that could be revisisted. it would be a complication, but it seems to me better than a http-like protocol, bundling requets together or moving to a storage- oriented protocol. - erik
