You are instructing the client to access the R/W volume which
exists on A. Therefore, if A is down there is no volume for
the client to access. Failover only occurs from R/O to R/O.
Jeffrey Altman
Walter Lamagna wrote:
> Another interesting data is that when Server A is down, in Server B i
>
Here is more information, Server A is named "Turing" and has the
root.afs and root.cell RW volumes. Server B is "Retro".
# vos examine root.afs
root.afs 536870912 RW 4 K On-line
turing /vicepa
RWrite 536870912 ROnly 536870913 Backup 0
Ma
Your clients don't believe you.
What is the output of "vos examine root.afs" and "vos examine root.cell"?
Walter Lamagna wrote:
> I do have them already:
>
> Server A:
> root.afs
> root.afs.readonly
> root.cell
> root.cell.readonly
> documents.readonly
>
> Server B:
> root.afs.readonly
> root.
I do have them already:
Server A:
root.afs
root.afs.readonly
root.cell
root.cell.readonly
documents.readonly
Server B:
root.afs.readonly
root.cell.readonly
documents
Thanks,
Walter
On Wed, 2006-11-22 at 15:11 -0500, Jeffrey Altman wrote:
> Walter Lamagna wrote:
> > Hello, i am setting up afs
Walter Lamagna wrote:
> Hello, i am setting up afs replication and have a question.
>
> The Server A has the root.afs and root.cell RW volumes, also some RW and
> RO volumes. And Server B has some RW and RO volumes. It happens that
> when i shutdown server A, i can not access RW volumes in Server
Hello, i am setting up afs replication and have a question.
The Server A has the root.afs and root.cell RW volumes, also some RW and
RO volumes. And Server B has some RW and RO volumes. It happens that
when i shutdown server A, i can not access RW volumes in Server B,
though thouse RW volumes i w
Berthold Cogel schrieb:
Perhaps it is possible to include a script in openafs with a mechanism
that allows the user to update his CellServDB. It should be called by
the init script. This mechanism could be triggered also by local update
methods (cfengine) or manualy.
The init script could
My recommendation on installing a new host:
Have the own CellServDB installed before the afs rpm by some other means,
If the afs rpm finds an empty or no CellServDB, it should copy
CellServDB.public to CellServDB .
Mangling the own CellServDB isn't that good; we had to wait for one year
before ou
Berthold Cogel wrote:
> Derrick J Brashear schrieb:
>>
>> If we can get a vgaue consensus on what it is that should be sourced,
>> I'd love to accept and integrate such a contribution... as long as
>> people who don't have something set still get their DB updated. Having
>> one set of packages ever
Derrick J Brashear schrieb:
If we can get a vgaue consensus on what it is that should be sourced,
I'd love to accept and integrate such a contribution... as long as
people who don't have something set still get their DB updated. Having
one set of packages everyone can use, and no one needing
10 matches
Mail list logo