Infinite Recursion

[Chris Cowan]

Jon S. Stumpf writes:
 > Magnus Ahltorp wrote:
 > 
 > > > Actually, I'm wondering what DFS did in this case?  (Don't have
 > > > access to a system anymore).  But, I think it behaved correctly.
 > 
 > I doubt it behaved correctly.  AFS and DFS are represented by a single device
 > number in the UNIX filesystem table.  Volume/fileset mount points must be tested
 > using the AFS/DFS system call extensions via pioctl, I believe.  (It has been a
 > while since I touched this.)


I'll have to go look and see too.  Actually, I can't look at AFS
source at all!   (And, I presently don't have enough space at home for the
OpenGroup DCE/DFS source).

However, Episode (LFS) filesets are mountable locally, sans
fileserver on AIX.  And in fact, each fileset maps into a unique
logical volume device.

I know that the kernel extensions for DFS handled a lot more of the
dirty work than AFS.   But, they had to.


 > 
 > > I agree. It would be nice (volume boundaries are the way to go), I
 > > have no idea on how they have implemented this. It's possible to
 > > change device numbers at each volume boundary, but I don't know if
 > > that is a good solution (sounds like a hairy thing to do, besides,
 > > linux support would break).
 > >
 > > Ideas are welcome.


 > I don't believe changing device numbers is necessarily the right way to go.
 > 
 > An idea is to formally set a flag in the stat structure that indicates if this
 > entry is a mountpoint and require the stat() call to provide this information.
 > An application would check this bit for true to determine if this directory was
 > a mountpoint.  POSIX would be updated and each VFS-specific stat() call would
 > have to be modifed to provide this information correctly.  Essentially, I am


I think this was in fact done with DFS, on AIX.  But, I can no longer
verify this. 


 > trying to propose a "standard" method of testing for a mountpoint rather than
 > relying on a change in st_dev to indicate it.  This suggestion would still force
 > application changes initially but would permit a "standard" way of passing this
 > special information up through standard calls.  The test should come out of the
 > stat() call, in my opinion.


 > Since this idea won't happen in a timeframe one would find practical, we have to
 > change the utilities.

I guess this is where we disagree.  I don't view changing the
utilities and applications as the best approach.  It relates directly
to acceptance and useability.


 > Assuming that arla is targeting the FreeOS market, many of the GNU utilities
 > already include patches (and/or #ifdef conditionals) to become AFS-aware.  For
 > those utilities that are not currently aware, fix them once in the standard
 > distribution and answer "yes" to an autoconf question "Are you using AFS?".
 > 
 > - jss
 > 

Well that's the crux of the problem.  In most cases, these changes
have not been integrated.  In my experience this question is usually asked to:
- Establish the authentication technique. Particularly to determine
what flavor of Kerberos is in use.
- Allow for the installation of the executables in one place and
execution in another. (e.g. perl, tcl). 

In a very small number of cases is this question asked as you are
implying. (Not surprising these packages come from Transarc, CMU, MIT,
UMich, ...)  And yes, I realize that it is very easy to use GNU
autoconf. 

I guess it comes down to who the target user community is.   After
supporting AFS and DFS for customers who ranged from Kernel developers
to manufacturing techs, I changed my outlook on this.   I used to
think the almost-POSIX model was just fine.  Now, I think it has
problems.  (Although I will admit that Magnus mentioned the Coda model
in an off-line note.   I need to look at that further).

Granted, my motivation to support things like ARLA is "It's not
CIFS/SMB!"  

-- 
Chris Cowan
ceez at bga.com