[OpenAFS] Move a IP from CellServer?

Fri, 12 Nov 2004 12:57:36 +0100

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

Horst Birthelmer schrieb:
|
| On Nov 12, 2004, at 11:37 AM, Lars Schimmer wrote:
|
|> 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.
|>
|
| No, the database server doesn't matter. If you work with the RO copy you
| cannot change it. That's the way it is ;-) (That's why it's called RO ...)
| I think your problem is a misunderstanding of the concept. You cannot
| balance between the RW copy and the RO but between the ROs.
| If you mount the volume RW you will loose contact when your server goes
| down (the RW is unique). If you want replication you can do that but
| only with read only data.
|
| The root.cell isn't on your database server. (It might be the same
| machine) It has nothing to do with what database server is serving you.

Maybe we misunderstood each other :-)
I've got one special problem right now and try to solve it the right way, so
that this salvage is the answer to all other problems that kind.
We've got the volume subversion mounted (it was only ONE RW volume, so mounted
as RW in the tree). After that I added a few replicas and the backup database
server.
Now, after a few reboots of the database servers and releases of the volume, I
try to mount another volume under the mountpoint subversion, but afs tells me
"ro volume". So it uses the RO copy. And my problem is to change this RO to RW
on only ONE afs machine we got to mount the new volume. But til yet every
machine has mounted the RO copy. From my understanding, ther MUST be one machine
with the RW copy mounted, or? At least the first database server, because this
one has the RW root.cell and so all mounted volumes on this servers are RW. But
this example now shows that I'm wrong. But where is the RW mounted volume
subversion?
That there is no balance between RO and RW is clear. And that I cannot change
RO, is clear, to.

The root.cell is a volume on the first database/fileserver, and ro copys of it
on every fileserver we've got. Yes, it's independet of the databse servers, but
it describes the cell and should be mounted RW on at least one server.
Oh, where is the information of mounted RW volumes stored? In the database
servers? If yes, how can i change the mount RO to RW (e.g. changing from RO copy
to RW volume)?

|> |> 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?
|
|
| I'm heavily under the impression we're talking about different mounts here.
| You can mount any volume at any point in AFS at any time (if you're
| allowed to) and in any mode even if that's not the same volume from the
| same server (RO/RW).

Yes, free mounts as I like to. But if you mount the "head" of the cell,
root.cell, RO everything else "under" it is RO. Or am I wrong?
So the "head" has top be RW to get a RW mount in the tree, or?

|> ~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 ;-)
|
|
| That's pretty useless.
| You're keeping too much data on too much servers. That's what backups
| are for ... or RAIDs or whatever but not AFS.
| Why would you want to create an inconsistency?? (and really knowing
| better) We have "sync on close" on files on the RW so what keeps your
| client from _reading_ that data?? (Maybe it's a "cool" concept ;-) )

Backups are nice, yes, but in OpenAFS you have to bakup each volumes. Til yet we
don't have this implented, so the RO copies :-)
Raid would be nice, but with AFS speed at least don't count (we've got 2-4
MB/Sec), and a RAID doesn't replace a backup, so we better use volumes (which
are more atomic) and RO copies on different HDs and Servers.
Yes, It take more space on HD, but for now it works.
"aync on close" seems to be what I'm looking for.
But my point was: We use OpenAFS for home dirs. On home dirs RO is pretty
useless, EVERY login wants to write on the homedir and a lot of programs writes
data to the homedir. So a RO wouldn't work with RO. As my understanding RO
copies in AFS are for loadbalancing between the servers (shortest "way" from
server to user). But with the NEED to be RW, there could be only one volume for
users-homdir-volume. And so there is no loadbalacing more. At least this breaks
with the original use for RO copies, and makes the RO interesting for backup (1
day or what the release cycle is).
But IF there are a few more RO copies from the volume and the clients would read
from RO, they could loadbalance the read (which is in practical use far more
than writing to a volume) and concentrate the write to the one RW and sync then
the RW to the RO, so that this one is synced and the clients got the new data.
And in our cell we've got mor than the home dirs in which users has to write
data (work dirs, CVS,..), so it's really a messe here :-)

Yes, thats right. But I meant this for our use, for now the RO copies are only
for data-volumes easy and fast to be recoveres useful in our cell. At least not
very usefull for us than....
So we use them as a kind of backup (reaching back to the last release).

At least this all about learning to understand AFS and getting an info about:
How to add the volume under subversion ;-)

| 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

iD8DBQFBlKUwVguzrLh6DgMRAnPIAJ9CoZG9sj7lFogjNfEhYchgw/L6aACgtpIx
8qimhJqEP06m3ZEMKsFZemE=
=RKa4
-----END PGP SIGNATURE-----