> But if the home directories are set to the RW paths, then there will be
> no failover to the RO volumes.   The RW paths will only access the RW
> volumes.

No automatic, no. But since the RO volumes exist, users can still
explicitly use that to get their work done (saving changes somewhere else)
while the RW volume is down. To my understanding this is the best any
networked filesystem has to offer except perhaps Coda, which supports
disconnected operation. A failed server is essentially the same as
disconnected operation at least until you need to resync the client cache
with the new server, which probably was restored from tapes and does not
have exactly the same versions of the files as the previous server had at
the time the client cached them... Calls for lots of conflict resolution
by hand. Besides I got the impression that coda is not very transparent
with PAM and friends. (And OpenAFS looks more reliable, too.)

> is the volume pointed to by /afs/tfy.utu.fi/ a RO volume and is it
> replicated?

Eh..? It's RO replica of a RW volume. If you mean that there should be two
RO volumes, then no. That was exactly the situation where this do not
work. (At least if the other RO is on server A like the RW volume.)

> is the volume pointed to by /afs/tfy.utu.fi/home/ a RO volume and is it
> replicated?

Same as above.

> is the volume pointed to by /afs/tfy.utu.fi/home/username/ a RO volume
> and is it replicated?

Still the same. All of these directories also have .versions, which are
the RW mountpoints.

~> fs lsm /afs/tfy.utu.fi
'/afs/tfy.utu.fi' is a mount point for volume '#tfy.utu.fi:root.cell'
~> fs lq /afs/tfy.utu.fi
root.cell.readonly <quota info>

~> fs lsm /afs/.tfy.utu.fi
'/afs/.tfy.utu.fi' is a mount point for volume '%tfy.utu.fi:root.cell'
~> fs lq /afs/.tfy.utu.fi
root.cell <quota info>

This is how it should be, as far as I understood the OpenAFS docs
correctly.

> Normally you want a RO replica on the same machine as the RW volume in
> order to reduce the time the RW volume is inaccessible during the volume
> release process.  Once the release is done locally the RO only copy can
> be sync'd with the rest of the replicas.

Just as I've understood things, but for some reason this results in
inaccessible files on the RO volumes, when server A is lost. Getting rid
of the RO volume on A and then unplugging A keeps the RO volume
accessible, naturally. I did not, however, test the situation with RO
volumes on B and C, then unplugging one of those (leaving A on-line). If
this produces the same result, then the whole failover would seem broken,
would it not? Perhaps I should test this?

> If this is how you have things setup and the clients are not failing
> over to another server, we would need to know what clients you are
> running.

Everything runs linux with Debian/Sarge and its OpenAFS packages; that
means OpenAFS version 1.3.81 atop kernel 2.6.8.

-Juha

-- 
                 -----------------------------------------------
                | Juha Jäykkä, [EMAIL PROTECTED]                        |
                | Laboratory of Theoretical Physics             |
                | Department of Physics, University of Turku    |
                | home: http://www.utu.fi/~juolja/              |
                 -----------------------------------------------

Attachment: pgpicCeZdUu6c.pgp
Description: PGP signature

Reply via email to