[OpenAFS] mount points and replication problems

[Frank Burkhardt]

Hi,

On Tue, Jul 12, 2005 at 01:17:05PM +0200, C?dric CACHAT wrote:
> Hello,
> 
> this is the first time I write and I am pretty new to AFS. I have a 
> question regarding mount points in AFS.
> Here is what I'm trying to achieve:
> I want all my users to have their home directory in AFS, the plan is to 
> set an AFS tree looking like:
> /afs/cell/usr/homes/<user1>
> I created the following volumes on my primary server:
> root.afs
> root.cell
> common.usr
> common.homes
> user.user1
> and then I mounted them using the fs command :
> *# fs mkm /afs/cell/usr common.usr* and so on... (I didnt use *# fs mkm 
> /afs/_._cell/usr common.usr *maybe my problem comes from here?)
> So far everything is under control.

Did you explicitely mount the RW-instance of the homedirectory-volumes?

-> fs mkm /afs/cell/usr/homes/user1 user.user1 -rw
                                               ===

Otherwise you would have RW-acces to the homdirs only if there are
no RO-copies.

> Since I have many sites, I have set up one AFS server on each site. 
> Because all users don't work on the same site I decided to create user.* 
> volumes on their closest server, so I created volume user.user1 on the 
> primary server and user.user2 on the secondary server.
> Without any replication it works perfectly if BOTH servers are running. 
> If one is down, say the master, then acces to a user's home-dir is 
> impossible.
> Thats's were it's getting complicated for me: I then set up replication 
> to the second site so that I have:
> 
> primary server 	secondary server
> root.afs (RW) 	root.afs (RO)
> root.cell (RW) 	root.cell (RO)
> common.usr (RW) 	common.usr (RO)
> common.homes (RW) 	common.homes (RO)
> user.user1 (RW) 	user.user1 (RO)
> user.user2 (RO)
> 	user.user2 (RW)

You most probably want to have RO-copies of "structural volumes" like
root.afs, root.cell, common.usr, common.homes on both fileservers.

> Looking at the array above, if the primary server is down, user1 should 
> be able to access is home dir but Read Only whereas user2 should be able 
> to read/write to his home directory.

No. user.user2 resides on primary-server so user2 will have no access at all.



> That's exactly what I want.
> The problem is user2 can only read and not write (il I try ls 

See '-rw' -option of 'fs mkm'.

> /afs/.cell, it hangs then says timeout). Is it normal or did I miss a thing?
> Second question, I don't know what to set their homedirectory to (read 
> from LDAP at login), do I have to use /afs/_cell_/usr/homes/user1 or 
> /afs/_.cell_/usr/homes/user1.

The first. There should be no "dot-path-component" in a user's homedir as long
as you mount the homedir-volume '-rw'.

> If I use the former, when both servers are running they can't write to 
> their directory, they have to cd to /afs/.cell/usr/homes/user1 in order 
> to write which is not practical; if I use the latter, it works all right 
> when both servers are running but when the primary is down, it fails to 
> acces the home directory (server timeout, the branch /afs/.cell is down).

That's expected behaviour because root.cell(RW) (aka. /afs/.cell) resides
on primary-server.

> Did someone ever try to set up such a network, or is it impossible? 

Impossible is to automagically switch a user's homedir to RO when there's
no RW-volume available. That's because the '-rw'-switch forces the AFS-client
to mount the RW-volume - *without* any fallback to RO.

> Could you tell me then how should I mount my tree?

/afs                 root.afs
 |- cell             root.cell
 |  `- home          homes
 |     `- user1      user.user1(-rw)
 |- .cell            root.cell(-rw)
 |  ...

> I think my problems come from the .cell and cell, I don't quite 
> understand the impact it has on the rest of the tree.

Whenever you want to i.e. add a user, just access /afs/.cell/home,
add the mountpoint and 'vos release' the homes-volume.

All volumes along the path (root.afs, root.cell, homes) should have
RO-instances on both fileservers.

Your users needn't access .-paths.

Regards,

Frank