A.Eric@GSB-HOW.STANFORD.EDU (Eric M. Berg) (04/20/88)
We're getting ready to move our faculty into a new office building which
will be equipped with an extensive AppleTalk network linking Macs and
MS-DOS PCs to each other, printers, and our campus Ethernet. At a rather
late date in the planning, it was decided that some of the commercial
AppleTalk products weren't quite in a state where we felt comfortable
using them, and so we've been scrambling to get some of the CAP programs
(papif, lwsrv, and most recently, aufs) running.
After a bit of experimentation and a lot of help from people on campus, we
now have each of these programs running. However, a few days ago, we
discovered that MS-DOS PCs running Apple's "AppleShare PC" product don't
seem to be able to use our aufs file server.
The PC-based AppleShare program includes a component called "da" which
performs functions corresponding to those of the "Chooser" on a Mac. We
can get as far as selecting "AppleShare" (as opposed to "LaserWriter",
etc.), selecting the aufs server, and supplying a user-name and password.
The server validates the password, and then sends back a list of available
AppleShare volumes. When we select the volume to be mounted and then
press "F2" to actually mount it, the PC displays the legend "adding icon"
at the bottom of the "da" window, and then hangs. We end up having to
reboot it, and the AppleShare volume never gets mounted.
When we look at the aufs log on the Unix side, we see the following:
00092* 15:18:05 03/18/88 pid 1005 starting for session 0
00092* 15:18:05 03/18/88 Waiting for session 2 to activate
01005: 15:18:06 03/18/88 Login: user aufsuser, home directory
/usr/user/aufsuser
00092* 15:18:25 03/18/88 Server timeout on session 1 pid 1000, not talking to
remote anymore
01000: 15:18:25 03/18/88 Superior told us to shutdown - probably tickle
timeout
00092* 15:18:40 03/18/88 session for pid 1000 closed by timeout or non-aufs
child died
each time we try to log on, which is consistent with the fact that the server
session just hangs. [Note that for some reason, the month is off-by-one;
this really happened Monday.]
Just to keep things amusing, the following things do work: (1) logging on
to the aufs server from a Macintosh on the same AppleTalk network; and (2)
logging on to an AppleShare server running on a Macintosh from the same
PC. (In the latter case, the "adding icon" message is seen very briefly,
and is then replaced by a message indicating that the server has been
mounted as the "D:" drive.)
I guess that there must be some difference between Apple's AppleShare
client software for the Mac and for the PC, *and* some difference between
Apple's AppleShare server and aufs, such that {Mac server, PC client} and
{aufs server, Mac client} work, but {aufs server, PC client} won't.
So, the question is, has anyone had any luck using aufs from a PC running
AppleShare PC? Does anyone know why it wouldn't work? Or have any
suggestions as to how to fix it?
Another question: one reason we're trying to use aufs and not a Mac server
is that we want to avoid the 25-logged-in-users that the Mac AppleShare
server software enforces for MacSE servers (and avoid dedicating a MacII
as a server!).
To clarify, while we anticipate that more than 25 people might be logged
in to the AppleShare server at once, we do NOT anticipate that any significant
number of them will be active (storing or retrieving files) at the same time.
In fact, AppleShare is being used primarily for file _transfer_ (between
users, including between faculty with PCs and secretaries with Macs) rather
than file _storage_. (In fact, we aren't even giving users their own
fileserver accounts... everyone will log in to one big scratch area.)
[The reason that we're doing it this way is that we're eventually planning
to run PacerShare or AlisaTalk or something on our new VAX/VMS system, where
each user will have their own directory anyway. Mac- or aufs-based servers
are a temporary expedient until we get that working. Yes, we know about
TOPS as an alternative mechanism for file-exchange, but we've decided not
to use that.]
The question: does anyone know what having > 25 users logged-in to the
aufs server at once will do to performance, given that most of them will
be inactive most of the time? The server is a MicroVax II with 16 meg. of
memory; it is only being used for network services (altalkad, lwsrv, print
spooling via lpr and papif, and aufs), not for general timesharing. (In
particular, I'm concerned about the fact that aufs creates a new process
for each logged-in user of the server; I'm not sure what the impact of
30 - 50 extra processes will be, given that most of them will be idle.)
Thanks for any light that anyone can shed on either of these problems.
Eric M. Berg
Computer Facility
Graduate School of Business
Stanford University
-------cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim) (04/20/88)
We made a decision a while back not to support MS-DOS clients. Even so, Aufs doesn't deal well with AppleShare PC clients because there are some points that errors should be returned (OpenDir, CloseDir) when they are not (fixed in new release). Somewhere in the mess that I call documentation for Aufs, this is duly and dully noted. Making Aufs work for MS-DOS clients is far from impossible, but it is a lot more work than I can presently justify (mostly it is a matter of handling short file names). Creating new process for every connection isn't that much overhead (beyond the initial fork call), but it is a decision that should be re-evaluated at some point. There are major advantages to running in a single fork. By the way, we have a MicroVax II (5MB memory, 2 RD53 driver) acting as a server for ~27 Aufs users, acting as an IP gateway, and a lpr server. Loads, for all they count, average around .25-.5. Our CPU utilization is within reasonable bounds. Our big problem is having enough memory to keep everything in core. The big thing is that people seem to be relatively happy with the performance. Charlie C. Kim User Services