[OpenAFS] RO v. RW path not behaving on setup

Steven N. Hirsch shirsch@adelphia.net
Sat, 28 Jun 2003 13:19:15 -0400 (EDT)


On Sat, 28 Jun 2003, Derrick J Brashear wrote:

> On Sat, 28 Jun 2003, Steven N. Hirsch wrote:
> 
> > At this juncture, 'fs examine' should be showing the *.readonly volumes on
> > /afs and /afs/my_cell respectively.  Unfortunately, this does not happen.
> > I continue to see the rw volumes on both mount points - even after doing
> > fs checkvol.
> 
> No it shouldn't. You mounted root.afs, not root.afs.readonly. You get
> root.afs.

On p. 2-71 of the Transarc manual:

".. Verify that both volumes are now released.  First issue fs 
checkvolumes to force the Cache Manager to notice that you have released 
ReadOnly versions of the volumes, then issue fs examine again. This time 
the output should mention root.afs.readonly and root.cell.readonly instead 
of the ReadWrite versions, since the Cache Manager has a built-in bias to 
access the ReadOnly version of root.afs if it exists."

This is not how it works.  I continue to see the root.afs and root.cell 
volumes until after an oops, shutdown and reboot cycle, at which point the 
*.readonly volumes show up on those mount points!


> > When I attempt to stop AFS, 'umount' causes a kernel oops and the AFS
> > client daemons refuse to shut down.  After rebooting the server,
> > everything _seems_ to look right!  Both /afs and /afs/my_cell show up as
> > being the *.readonly variants.  But, now I am unable to get proper RO/RW
> > pathing behavior.
> 
> I've seen this bug but it went away when I switched to a newer kernel;
> What are you running?

2.4.21-pre2, which ran stable and flawlessly for months before I 
accidently nuked the /vicepa partition.  Never had a shutdown problem.

> > Example: I create a volume called my_cell.users, mount it under
> > /afs/.my_cell and release it.  It then shows up under /afs/my_cell, but
> > acts as an RO volume - the cache manager does not follow the correct path
> > on writes.  I've removed all volumes and retried this sequence several
> > times with exactly the same results.
> 
> That sounds like how it's supposed to work. /afs/my_cell is RO, you make
> an RO, you get an RO. You want writes, you do into /afs/.my_cell, or you
> donm't replicate the volume.

Color me confused, then.  Previously, as a user I never needed to go into 
the /afs/.my_cell explicitly to create/write a file.  Assuming that I have 
the correct permissions, I would simply go to /afs/my_cell/blah, blah and 
write.  Per the documentation, I assumed the cache manager was silently 
accessing the rw volume in such cases.

I thought the entire point of replication was to always read from an RO 
volume, but force writes down the RW path?  Perhaps I'm either 
misunderstanding you or am completely lost...

Steve