> So why does replica use 9P? Because it's *The Plan 9 Protocol*. If > *The Plan 9 Protocol* turns out to not serve our needs, we need to > figure out why.
i appreciate the sentiment, but i think that's just taking it a wee bit overboard. we don't pretend that 9p replaces http, ftp, smtp, etc. venti/fossil don't even use 9p. nor does factotum, secstore nor the auth server. these last few might be mistakes, but it's clear that the thinking was never, we've got a 9p hammer, and all the world's a nail. that being said, i agree with steve. replica is a fine tool when used as intended. i think it assumes size(corpus) >> size(differences). when you use it as a file transfer mechanism, it doesn't work as well. note the bulk of plan 9 is distributed as an iso through http. this was necessary because before you have the iso, you don't have replica. (pre p9p, anyway.) so i don't see why bulk transfer would have been optimized. it's a simple tool for a narrow problem. and there are many ways to speed up replica if anyone cares to solve the problem. > You like to put forward devmnt's penchant for only having one > Tread/Twrite per process in flight at one time. I agree that this is a > problem, now, how do we fix it? All it needs is somebody willing to > rewrite devmnt... I think you may just have to rewrite mntrdwr to be > just a little smarter. Any takers? i think there are two things required. first, the mount driver needs to have the ability to send 1..n T(read write) messages at once (and therefore the ability to manage the number of outstanding) and a mount flag enabling multiple outstanding. bls suggssted that a mode bit could be added to each file. this would allow, e.g., exportfs to maintain multiple outstanding on some files but not others, but that would require an additional open mode that could be or'd with OREAD/OWRITE. - erik
