[OpenAFS] Move a IP from CellServer?

[Horst Birthelmer]

On Nov 12, 2004, at 12:57 PM, Lars Schimmer wrote:

> -----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.

That's right, that should be that way until you mount your volume r/w.

> 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.
>

So go to any other location (your home for example) and do fs mkmount  
... -rw make your changes and release the volume.
That's the design. The admin makes changes, releases the volume and 
every machine sees the changed data.

> 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.

You cannot mount anything differently an any machine. That's also this 
way by design. We have a global namespace and that's what global means.
Every client in the cell sees the same data (dependent on the access 
rights of the user logged in).

> 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)?

On the fileserver. Your mountoint is just a special entry in the parent 
directory.
So your root.cell is almost every time a mountpoint in the root.afs ... 
and so on.
Your volume location is in the VLDB. Do a "vos listvldb" and you'll see 
that data.

>
> | 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?
>

If there are RO copies of all the volumes, you're right, but that would 
be a wrong design of your cell.
AFS can't do the design of your cell for you.

> |> ~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.

Those were just examples what AFS can't do for you (don't take 'em that 
serious) ;-)

> 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).

Yes, but what's the breach in here ???

> 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 :-)
>

hey ... this is a free file system. When you're done implementing that, 
I'll talk about inconsistencies on your clients ... :-))
You have different data for reading and writing. Oh my, that's fun, 
isn't it??

The concept here is pretty simple. You need to write, you mount the RW 
volume.

> |> 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...?
> |>
> | RO copies are read only and can be kept on more than one server 
> because
> | they are read only and there is no need for consistency checks.
>
> 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 ;-)

Hope I was of any help ;-) I didn't mean to be rude but the concept of 
distribution in AFS is well thought out no matter if it is of any 
particular use to you.

Horst