Xref: utzoo comp.sys.mac:46536 comp.sys.mac.hardware:1229
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!pasteur!eris.berkeley.edu!korn
From: korn@eris.berkeley.edu (Peter "Arrgh" Korn)
Newsgroups: comp.sys.mac,comp.sys.mac.hardware
Subject: Re: CD-ROM players for Mac
Message-ID: <21253@pasteur.Berkeley.EDU>
Date: 18 Jan 90 07:27:43 GMT
References: <1990Jan10.181218.17218@aucs.uucp> <3632@hub.UUCP>
Sender: news@pasteur.Berkeley.EDU
Reply-To: korn@eris.berkeley.edu (Peter "Arrgh" Korn)
Distribution: na
Organization: What, me organized???
Lines: 53


In <3632@hub.UUCP>, you said:  
>
>I'm using the Apple CD on a AppleShare server and have had a couple
>probelms with it.  1) It's a major pain to "publish" a CD w/ AppleShare.
>Without going into the details, you have to shutdown the server and run
>the Admin application from a different disk.  Also, it took me a record
>_2_ hours (that's right, two hours) to publish Educorp 3.0, a PD CD with
>lots of small files.  2) It takes a bunch of time to actually get the
>server up-and-running with CDs online.  For some lame reason (it's lame
>because I don't understand this phenomen (sp?) yet) AppleShare has to
>check all of the files on the CD to "make sure it's readable".  Now, why
>on a write-protected media does it have to check, I don't know.
>...

There are a couple of ways to make things faster.  AppleShare wants to
keep user/group/world permissions information for every disk it serves.
It cannot write this stuff to a CD, so it writes it to a special file
(called the Parallel Directory Structure or PDS) which it keeps in the
Server Folder of the main server volume (boot volume).  The first time
you insert a foreign CD & try to serve it, AShare needs to walk the
disk and create this structure.  Once created, it can (optionally)
be kept on the server, even when that disk is not being served.
By keeping this structure around, the next time you want to serve that
disk it won't take forever for AShare to come up -- it'll already have
that PDS waiting there for use.

Now, the second issue with coming up slowly is: if the server was down
& not serving, but running as a mac (boot from floppy & diddle at
all with any of the writable drives it's serving) then the Server
must rebuild (or at least validate) the PDS; because if the PDS is
out of synch with what's actually on the disk, bad things can happen.

In fact, most of the time that the server spends checking things is to
ensure that the PDS is in synch with the file system.  When you boot
up the server, it does a quick check of all the disks being served to
make sure that the last modified dates match (and assumes that if this
is so, then the PDS is in synch).


One of the fastest ways to make your server faster is to make it a faster
machine; and to add memory to it.  AShare wants to cache the disk, and
if it can, will go a lot faster (20-50% depending upon how heavily
loaded).  Additional RAM will also help the initial PDS checking, and the 
initial creation of a PDS for a CD.

Hope this helps.

Peter
--
Peter "Arrgh" Korn
korn@mica.Berkeley.EDU
{decvax,hplabs,sdcsvax,ulysses,usenix}!ucbvax!mica!korn