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: 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