[OpenAFS] Re: Getting started with OpenAFS

[Jason Edgecombe]

Hi Mike,

Would you please elaborate on your tutorial comment? What should it 
contain? What key concepts need to be mentioned? Would you be willing to 
help write such a document or give some notes on what it should contain?

The challenge of many of the AFS veterans is that we cannot see things 
as a new user sees them.

Thanks,
Jason

Mike Pliskin wrote:
> Ok thanks for explaining that, maybe it makes sense to post this info into some tutorial online? In terms of geographical diversity, it's uncommon that people from different sites need to write the same info, so it's ok if it is a bit slow.
>
> Mike
>
> -----Original Message-----
> From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of Andrew Deason
> Sent: Friday, April 30, 2010 7:01 PM
> To: openafs-info@openafs.org
> Subject: [OpenAFS] Re: Getting started with OpenAFS
>
> On Fri, 30 Apr 2010 17:49:16 +0400
> Mike Pliskin <mike@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
> adeason@sinenomine.net
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> :��