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

[Nathan Neulinger]

Just wanted to check here - this may be the really obvious thing that is
being missed.

You said you made a mountpoint for ".my_cell". Did you specify "-rw" as
an option to the 'fs mkmount' command? If not, you didn't force it to be
read-write. There is nothing magic about the "." in the name, that's
just convention.

As for it staying RW until you restart the client - I think that
behavior is normal with root.afs due to how it gets mounted, but you
shouldn't see that behavior with any other volume. 

-- Nathan

On Sat, 2003-06-28 at 13:22, Steven N. Hirsch wrote:
> 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!
> > 
> > For the Linux client, at least, what you see is as far as I know how it's
> > always been.
> 
> Ok, I'll keep that in mind.
> 
> > 
> > > > > 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.
> > 
> > Well, it only happens when you mount a RW root.afs and then replicate it,
> > or at least that was the only time I could make it happen.
> 
> So, you do not recommend replicating root.afs then?  Given that I only 
> have a single server, should _anything_ be replicated?
> 
> > > > 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.
> > 
> > Sure. *Your directory* isn't replicated, so the right thing happens.
> 
> I left out that step, but yes it was replicated.  Still, as mentioned in 
> my earlier posting I was forced to explicitly point down the /afs/.my_cell 
> hierarchy as a user.
> 
> > 
> > > 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...
> > 
> > I think you're missing something.
> 
> Apparently.  I poked around on the Wiki, but couldn't find any links to an 
> AFS installation guide other than the Transarc one.  Is there a good 
> step-by-step writeup you can recommend?
> 
> Steve
> 
> 
> 
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
-- 

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216