Newsgroups: comp.protocols.nfs
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!ox.com!ox.com!emv
From: emv@ox.com (Ed Vielmetti)
Subject: Re: CD-ROM Jukebox with NFS?
In-Reply-To: raj@hpindwa.cup.hp.com's message of 11 Apr 91 17:26:07 GMT
Message-ID: <EMV.91Apr12192003@poe.aa.ox.com>
Sender: usenet@ox.com (Usenet News Administrator)
Organization: OTA Limited Partnership, Ann Arbor MI.
References: <7322@emory.mathcs.emory.edu> <36530003@hpindwa.cup.hp.com>
Date: Fri, 12 Apr 1991 23:20:06 GMT

In article <36530003@hpindwa.cup.hp.com> raj@hpindwa.cup.hp.com (Rick Jones) writes:

   They all (?) have platter change times measured in *seconds*. This
   isn't such a big deal when you access the device locally - you wait
   for as long as it takes for the data to come in. With NFS, things are
   a bit more impatient shall we say ;-) Being an application written on
   top of an 'unreliable' network, it retransmits and other fun things.

I suspect that a cd-rom jukebox would be much more palatable with a
filesystem like Transarc's AFS in front of it.  Stick a single
ordinary magnetic rotating disk as a cache in front of all of the CD
ROMs, and you should get reasonable performance if the locality of
reference patterns allow it.

a lot will depend on reference access patterns, the size of the files,
the amount of cache, etc.  opens for files which are not in the cache
are still going to be slow, but it should work out to be better
overall than just a pure NFS setup.

disclaimer: i don't work for Transarc, but I know people who are
working on AFS here at Michigan.

-- 
 Msen	Edward Vielmetti
/|---	moderator, comp.archives
	emv@msen.com

"With all of the attention and publicity focused on gigabit networks,
not much notice has been given to small and largely unfunded research
efforts which are studying innovative approaches for dealing with
technical issues within the constraints of economic science."  
							RFC 1216
