On Fri, 30 Apr 2010 17:49:16 +0400 Mike Pliskin <m...@area9.dk> wrote:
> Ok thanks a ton for explaining, the only point left is read-write and > read-only and how to separate those. So far it sounds like I will need > to have a setup like > /afs/public/data1 > /afs/public/data2 > /afs/public/data3 > /afs/user1/data1 > /afs/user2/data2 etc The general notion of ROs vs RWs sounds correct, but the path structure is annoying me :) Traditionally, the convention of paths goes something like this: /afs/<cellname>/<volume> for the RO path, and /afs/<cellname>/.<volume> for the RW path. (And /afs/.<cellname>/ provides an RW path for anything). So for example, you'd have /afs/area9.dk/.data1/, that some users can write to and fiddle around with. When someone/something decides it is time to release that data to all sites and make it 'public' via the RO paths, the data in /afs/area9.dk/.data1/ becomes synced with /afs/area9.dk/data1/. You 'decide' this by running a command (specifically 'vos release'). Then people can read the new stuff in /afs/area9.dk/data1/ by accessing one of many servers. I'm not really sure I'm clear on your usage, though... you have data which will be 'accessed' by geographically diverse clients. But it helps to clarify 'access' into 'read' and 'write'. Do you have people from multiple different sites that will be writing to the same set of data? As far as I know, that will always be slow, since you must at least contact the remote sites immediately, or you risk cache coherence problems. -- Andrew Deason adea...@sinenomine.net _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info