On 6/4/07, Andrew Radamis <[EMAIL PROTECTED]> wrote:
... In this scenario we have two site, cleverly named site A and B. At each site has an AFS server and a some client computers running afs. Both sites are in the same cell and connected by a slow link(VPN or what-not). There are 2 types of users, users who are always at there home site, and users who may roam. Users may or may not use the same computer at each site. The first type of users are obviously not the problem. Which brings me to my question. A cache volume is my idea of a solution. It would be similar to a replication site with the exception of users being able to write to it. I understand why users can't write to normal replication sites so I'd assume the cache volume would need the additional stipulation of it can only be used when the real volume exists and is online. Files will need to copied to the remote server, this can I suppose be done through making the client wait till done, or letting the cache volume accept it and background send it. Second one would be preferred of course, but does have the problem of it the user beats the upload to the other office.
Your proposal would be a very large change to how AFS works. However, on a small scale, you might accomplish similar functionality manually via examining the cache and doing vos move's. As the number of users increases (and especially the number of shared volumes) , you'll need to re-architect a solution. But I suspect that solution can be more easily layered on top of AFS rather than done in AFS itself. I strongly suspect virtually every AFS site that is geographically distributed has dealt with this problem one way or another. As long as you don't have lots of RW data that is shared across a WAN, vos move's should suffice. If you have questions on how that might work, feel free to elaborate. Steven
