[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