[OpenAFS] Move a IP from CellServer?

[Lars Schimmer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Horst Birthelmer schrieb:
|
| On Nov 11, 2004, at 12:10 PM, Lars Schimmer wrote:
|
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Hi!
|>
|> Yeah, me again. I like to thank you all first, to built up a AFS Cell
|> is not as
|> easy as it seems.
|>
|> Is it possible (in a easy way), to change a IP from the first (main)
|> CellServer?
|> Background:
|> We set up first a test Server for our cell with a high IP (>.200). But
|> after it
|> works, this server got our main server for database and files in our
|> cell.
|> After a while I set up another database server with a lower ip (<.100)
|> as a
|> backup for the database server.
|
|
| That's perfectly normal and it doesn't hurt ... :-)
| This server's getting sync site and as long as everything's working you
| won't notice who's who.
| That's how ubik should be working.
|
|> But I think THIS was a big error, because now most of the clients take
|> the
|> information from the backup server (in which the cell is RO) and not
|> from the
|> first one. So we can't mount any new volumes in our cell, because it's
|> readonly :-(
|>
|
| That isn't something wrong. When you have replicas and you didn't mount
| root.cell read/write (what you shouldn't) that's normal behavior.
| Just make another mountpoint somewhere else with the root.cell mounted
| RW make your changes and release the volume. That's how you do replication.

Yeah, replicate is easy, but mounting a new volume doesn't work.
Example: volume subversion with submounts a b c d ...
So the submounts are mounted RW, but the subversion volume seems to be RO.
Even on BOTH database servers and every fileserver we've got. Why, I don't know,
but with only the RO copy of the subversion volume, I can't mount another volume
under ../subversion/t or else. Even fs rmmount subversion doesn't work.
fs: You can not change a backup or readonly volume Is the error to be faced with.
And I can't understnad why the first database server with the original Root.cell
(which was mounted RW) puts out this message, to.

|> Point 2: We thought the 2nd server to takeover the management if the
|> first gone
|> down. But while a reboot of the first (main) server, our cell hung and
|> no client
|> worked well. Is this a kind of wrong thinking of us? Or a failure of
|> OpenAFS
|>
|
| If you have just two of 'em that's also pretty much normal behavior. If
| you reboot the sync site you'll have some "out" time (timeouts) until
| the client notices that the server isn't there. It should actually work
| afterwards.
| If you reboot the server with your root.afs and/or your root.cell that's
| also normal.

Oh, with 3 database Servers it runs better?
And why shouldn't I mount the root.cell RW on the other Database servers?
At least, how can I remount the root.cell IF it is already mounted?
~From our point of view OpenAFS is a filesystem distributed on our PCs at work.
And we need nearly all volumes to be RW for most people (home-directory,
work-directorys, CVS, FTP,....) So for us the RO replicas are mostly only for
backup. It would be nice if the OpenAFS Client could read the Data from the RO
copies, write to the RW and sync them after writing. But that's heavy work &
load ;-)
In our view the only sense for RO copies to be public are archives like CDs or
other static data, but these are big data and easily and fast recoverable, so
why RO backups...?

| I don't see any AFS fault in what you were describing.

Not at least, more a user error, but I try to learn.

| Horst

Cya
Lars
- --
- -----------------------------------------------------------------
Technische Universität Braunschweig, Institut für Computergraphik
Tel.: +49 531 391-2109            E-Mail: schimmer@cg.cs.tu-bs.de
PGP-Key-ID: 0xB87A0E03


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBlJJrVguzrLh6DgMRAoDIAKDGl8DzBYdg/KUNVbrlBFuc1hl1owCfRsFV
1PwGKny/tG/R1ORY2KwSWI0=
=Rh1O
-----END PGP SIGNATURE-----