On Fri, Feb 18, 2011 at 12:15 PM, erik quanstrom <quans...@quanstro.net> wrote: >> > i don't think that it makes sense to say that since replica >> > is slow and hg/rsync are fast, it follows that 9p is slow. >> >> It is the other way around. 9p can't handle latency so on >> high latency pipes programs using 9p won't be as fast as >> programs using streaming (instead of rpc). Granted that there >> are many other factors when it comes to hg & replica but >> latency is a major one. > > you're still comparing apples and girraffes. rsync/hg have > protocols ment for syncing. replica uses 9p, which is not a > protocol designed for syncing. it's designed for regular file > access. it would be similarly difficult to use rsync's protocol > directly for file access. >
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. 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? 9P as specified in the documentation might not necessarily be the problem, but the implementation apparently is. > while 9p can and should be improved upon, this case doesn't > seem like a real motivator. the nfs guys don't complain similarly > about nfs loosing to rsync. > > - erik I don't see the NFS guys pretending that NFS is a good protocol for transferring large files across high-latency links... I've only ever heard of it being used in LAN environments. Yet 9P, which is not really that dissimilar for NFS in basic concept, gets presented as something we ought to be using over the Internet, for example to keep our systems updated. John
