Xref: utzoo comp.sys.mac.programmer:19513 comp.sys.mac.system:2443 comp.protocols.appletalk:4873
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!panix!alexis
From: alexis@panix.uucp (Alexis Rosen)
Newsgroups: comp.sys.mac.programmer,comp.sys.mac.system,comp.protocols.appletalk
Subject: Change in FCB structure in System 7? (for file servers)
Message-ID: <1990Dec4.013359.25319@panix.uucp>
Date: 4 Dec 90 01:33:59 GMT
Organization: PANIX - Public Access Unix Systems of NY
Lines: 45

(excuse the crossposting, but I think that in this case it's merited...)

One of the most serious fundamental limitations of the Mac OS is the maximum
maximum number of open files. The standard maximum is 40 (4* number in boot
blocks) but the maximum maximum is, I believe, somewhere around 86. This
limitation is a critical bottleneck for non-dedicated file servers like
allShare and DataClub.

For some users, this limitation make file service almost useless. For example,
I have one FoxBase application which can only run on two workstations at once
becuase the third workstation needs more open files than allShare or DataClub
can provide.

AppleShare ameliorates this problem slightly, by allowing up to 160 (?) open
files on a Mac II-level server. This is still a major limitation, and compared
to a typical PC (Novell or 3Com) or NFS server, it looks pathetic.

The big problem is that, for some reason, file refnums are 15-bit offsets from
a point in the system heap. This is the base of a memory block which contains
all the FCBs. So the maximum number of files open can never exceed 32767
divided by the size of an FCB.

I don't know why things were done this way, but it seems to me (and to several
people I've talked to) that this situation could be easily fixed by changing
the refnum from an offset to an index. This would have a negligable effect on
file system performance, and would allow up to 32K (or, in fact, 64K) open
files, without changing any data structures in the file manager.

I seem to remember someone telling me that this had actually been done in
System 7, but I'm not sure, and I didn't see any mention of this in a quick
glance at the 7.0b1 CD. Does anyone know if this is actually going to be done
in 7, and if not, why? Is there some major compatability problem I'm missing?
As far as I can see, virtually nothing anywhere would depend on this. I can't
even think of an INIT of disk utility that would care.

Now, if System 7 does _not_ address this issue, and there are in fact no
serious dependancies on the nature of the refnum, perhaps it wouldn't be too
difficult to patch out the part of the file manager that deals with this?
Does anyone know enough about this to say anything?

Sick of Novell servers,
---
Alexis Rosen
Owner/Sysadmin, PANIX Public Access Unix, NY
{cmcl2,apple}!panix!alexis


Brought to you by Super Global Mega Corp .com