On Thu, 17 Jun 2010 01:06:34 +0200 Jaap Winius <jwin...@umrk.nl> wrote:
> In an organization where it is only necessary for an administrator to > either give users read-write access to volumes, or no access at all, > what would be the advantage of creating any read-only replicas, beyond > those for the standard volumes at the root of the AFS namespace? If you're only using volumes for home directories, or things like group collaboration space, then RO volumes are not very useful to you. RO volumes are most useful for serving data that is assumed to be unchanging for at least some amount of time. For example, it is useful to put software binaries or scripts into AFS. Or web pages/scripts, or any data that doesn't change much but needs to be read by a lot of people. Or directories that just hold mount points, of course, like /afs/cell.name or /afs/cell.name/user etc. It's anything you can say something like "okay, I am releasing version 1.83 of this software" or "this website" or "this directory". You can kinda jury rig RO volumes into other situations, but it's really annoying; some places end up doing things like releasing a volume every N minutes to give the illusion of near-real-time updated load-balanced data. Ugh. As you mentioned, they can also 'kinda' be used for backup purposes, but you usually just use '.backup' volumes for that purpose. You can, however, distribute RO volumes for a sort of warm-spare backup volume. Say, if you have 5 RO sites for a volume, and the server with the RW fails, you can convert one of the existing RO volumes into an RW. I definitely wouldn't recommend that for home dirs or anything like that, though, since from the user's perspective it looks like their data just suddenly went back in time by a day. Usually it's not much better than just having real backups. -- Andrew Deason adea...@sinenomine.net _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info