[376] in arla-drinkers
Re: Infinite Recursion
daemon@ATHENA.MIT.EDU (Chris Cowan)
Tue Nov 3 00:41:01 1998
From owner-arla-drinkers@stacken.kth.se Tue Nov 03 05:41:01 1998
Return-Path: <owner-arla-drinkers@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 4394 invoked from network); 3 Nov 1998 05:41:00 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 3 Nov 1998 05:41:00 -0000
Received: (from majordom@localhost)
by sundance.stacken.kth.se (8.8.8/8.8.8) id GAA29064
for arla-drinkers-list; Tue, 3 Nov 1998 06:36:05 +0100 (MET)
Received: from mail1.realtime.net (mail1.realtime.net [205.238.128.217])
by sundance.stacken.kth.se (8.8.8/8.8.8) with SMTP id GAA29056
for <arla-drinkers@stacken.kth.se>; Tue, 3 Nov 1998 06:35:59 +0100 (MET)
Received: (qmail 30270 invoked from network); 3 Nov 1998 05:34:40 -0000
Received: from jake.bga.com (ceez@205.238.183.31)
by mail1.realtime.net with SMTP; 3 Nov 1998 05:34:40 -0000
Received: (from ceez@localhost) by jake.bga.com (8.6.12/8.6.10) id XAA06031; Mon, 2 Nov 1998 23:35:52 -0600
Date: Mon, 2 Nov 1998 23:35:52 -0600
From: Chris Cowan <ceez@bga.com>
Message-Id: <199811030535.XAA06031@jake.bga.com>
To: "Jon S. Stumpf" <jon.stumpf@acm.org>
Cc: Magnus Ahltorp <map@stacken.kth.se>, ceez@bga.com,
"Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net>,
Geoffrey Alan Washburn <gw2@andrew.cmu.edu>,
arla-drinkers@stacken.kth.se
Subject: Re: Infinite Recursion
In-Reply-To: <363E8608.F50D6350@mail.eclipse.net>
References: <199811030207.VAA00275@hilfy.ece.cmu.edu>
<lv1btmpijg4.fsf@sundance.stacken.kth.se>
<199811030308.VAA01986@jake.bga.com>
<lv17lxdihsv.fsf@sundance.stacken.kth.se>
<363E8608.F50D6350@mail.eclipse.net>
Reply-To: ceez@bga.com
Sender: owner-arla-drinkers@stacken.kth.se
Precedence: bulk
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@bga.com
