On Sun, Aug 8, 2010 at 3:10 AM, Charles Forsyth <fors...@terzarima.net>wrote:
> >Perhaps we could turn on async clunk for other files when the chan has > >CCACHE set (mount -C iirc). We already believe that the fileserver is > >'decent' then... > > that's more plausible, since you've declared that you're not interested > in certain details, but then the larger question arises: why pick on clunk? > in Op, the thing that reduces network latency is combining the sequence > open, (read|write), close > into a single operation. > When we tried out async Clunk in the Journal Callbacks work, it offered some fairly great improvements; and the details that it varies in are very minor compared to uncached 9p, particularly for decent fileservers. Since Clunk cannot fail, this also admits a simple (perhaps) approximation - issue the clunk as expected, but do not wait for RClunk. > services that wait for a close to commit, Hmm. Does this mean that any modification to devmnt, to keep a larger pool of FDs active for example, rather than clunking eagerly while walking, is unsafe? That would hold around directory FDs, which would make services like the above unhappy, or at least behave differently. Perhaps those file servers are assuming something not specified in the 9p definitions? Also, cyclic structures in Limbo with file descriptors embedded will not release the FD immediately after the outer structure is discarded. In a sense, that is also a delayed Clunk... -- vs
