On Mon, 4 Jun 2007, Steven Jenkins wrote:
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.
Actually, in some sense code to do this exists but is out of date. the
CITI folks had something called "iafs", which was basically "make my cache
manager also be a server". The access control model is of course going to
be fun, but it's doable.
Of course this is a development solution, not something you can roll out
of a box today, so Steven's answer is probably the one you want as an end
user unless you have a longer time scale in mind for this and have time or
resources to throw at fixing the problem.
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
