Wacky path-switching behavior

[Sarah Stockwell]

For better or worse, in our environment we already have 
multiple mount points for almost everything.  I figured out 
once that we have an average of about 23 paths to each 
volume, mostly due to top-level multiple mount-points that 
we've actually found very useful.  And actually, this is 
the first time it's caused a problem for us....  So in our 
environment, it's more practical to tell people not to use 
../ symlinks unless it's within the same volume, than it is 
to tell them not to make extra mount points.  That also 
resolves the problem of worrying about people tripping each 
other up by making extra mount points and breaking a "one 
true path" assumption.

$.02.  :-)

--Sarah Stockwell
  Qualcomm Inc.

> The problem is exercised when you cross AFS mount points, so making
> more of these will only increase your pain down the road.  If you 
> structure your cell so that each volume only has one logical mount
> point and all other paths to that volume use symlinks to reference
> "the one true path" then you won't have this problem anymore.
> 
> Of course, since anyone can create mount points and traverse them, 
> you're always at the mercy of the other users on a multi-user system 
> not to pull the rug out from under you.  In the AFS classes that I 
> teach I make a point of having the students create mount points to 
> each other's volumes to demonstrate the idea that the last mount 
> point traversal to the root of an AFS volume defines '..'.  Once
> they've gotten over their surprise they're more than willing to 
> adhere to the single mount point per volume philosophy.
> 
> Steve Mattson
> University of Michigan
> 
> 
>   Date:    Tue, 03 Apr 2001 16:07:14 -0700
>   To:      info-afs@transarc.ibm.com
>   cc:      afs-people@qualcomm.com
>   From:    Sarah Stockwell <sarahs@qualcomm.com>
>   Subject: Wacky path-switching behavior
> 
>   We had an odd problem at our site that took us a while to figure out, and I 
>   thought I'd share the solution in case anyone else comes across it.
>   
>   We have an application that people launch by hand out of a directory in an AF
>   S 
>   volume.  There's a symlink in that directory, ../../somefile, that points to 
>   a 
>   file in another volume.  That "somefile" volume is also mounted via another
>   AFS mount point elsewhere, and thus another path, which a separate, automated
>    
>   process invokes periodically (this is monitoring software).
>   
>   Occasionally, intermittently, the application launched by hand wouldn't be 
>   able read "somefile" (in our case, this meant no icons would be displayed in 
>   the app).  This was difficult to reproduce, and mystified us for a while.
>   
>   Solution:
>   It turns out that Solaris caches inode lookups for better performance.  It 
>   resolves symlinks when it comes across them, so it assumes (correctly for mos
>   t 
>   everything but AFS) that there is one, and only one, path to a given inode.  
>   Specifically, when the app is launched by hand, it caches the inode of 
>   "somefile" and the path associated with that inode (which is the path used by
>    
>   the hand-launched app).
>   
>   Given this assumption by Solaris, it's reasonable for it to behave as it does
>   : 
>   when another lookup happens on that machine that happens to be the same inode
>   , 
>   it bumps the old path associated with that inode out of the cache.
>   
>   So: "cwd", which looks at that cache, will give you the path by which you 
>   originally looked up the inode (i.e., cd'd to the directory), and the 
>   ../../somefile symlink will work.  So the app worked fine sometimes.  However
>   , 
>   when the automated process on the same machine woke up and accessed "somefile
>   "
>   via a different path, the first path was bumped out of the cache and replaced
>    
>   by the second, and "cwd" in the first process (dutifully reading the cache) 
>   suddenly gave a different result -- so the ../../somefile symlink ceased to
>   work.
>   
>   This doesn't matter unless you're relying on the environment not to change, a
>   s 
>   we were.  But it's startling.  :-)  We've worked around the problem (replace 
>   symlink with AFS mount point), but thought it might help someone to know abou
>   t
>   it.
>   
>   --Sarah Stockwell
>     UNIX System Administration
>     Qualcomm Inc.
>   
>   
>   
>   
>