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-ad...@openafs.org [mailto:openafs-info-ad...@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 <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
:��
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
