Re: CDROM jukebox filesystem using autofs

James Mastros (
Fri, 1 May 1998 21:59:03 -0400 (EDT)

On 1 May 1998, Aaron Passey wrote:
> On Thu, 30 Apr 1998, James Mastros <> wrote:
> >Probably, it would be best to make a driver (similar to loop) with a
> >number of minors equal to the number of CDs you will support. Make each
> >CD it's own device, and then the user can mount them normaly.
> Well, the problem with this scheme is that the jukebox I am working on
> has hundreds of CDs so taking into account partitions on CDs would mean
> thousands of minors. This is not reasonable with our current dev_t. It could
> work with devfs or a larger dev_t, I guess. It still seems like representing
> this jukebox as thousands of files in /dev is messy at best.

Hmmm... I'd tend to maintain that keeping each disk a sepperate device
would be cleaner then the other way around. However, your right that for
a huge disk array (well, huge to me -- I don't think I've ever used a
machine /w more then one CDROM drive though) you would use huge amounts of
minors (though you could pre-scan for multiple partitions, instead of
allowing room for 16 for each CD). However, I think one device, one
medium is a good rule -- what if sombody wants to cat out the whole CD?
(Or do "cdid /dev/cdjukebox115" to see what CD #115 has on it?)

> >Perhaps you should mount each CD, then make a httpfs (/w userfs, probably)
> >that reads through a squid cache? That way, you can easily (?) steal
> >(umm... leverage) existing cache logic, and, additionaly, make the
> >cd jukebox and the caching code independant of each other.
> Jeez, I hope you're kidding. :)

Mostly. But I do think that the agressive caching code should be
independant from the jukebox code -- after all, they don't need to be
conceptiuly related. You would want to do the same thing with
slow NFS or NBD, or tapes, or floppies, or ZIPs, or pretty much any type
of slow storage that is used on machines with plentiful memory.

> >It might be if you remove the code to not swap out data that we can
> >re-read from disk. Also, in your example, you would probably be able to
> >keep the RedHat CD in one drive -- if everybody's upgrading, they probably
> >aren't going to be playing mp3s off of the NFS server. <G>
> For performance reasons, we would probably want to cache the disk even
> if we have a free drive.

I supose -- though the page cache is probably enough for this case anyway.
With enough memory, the page cache will cache tons. The problem here is
mantaining control of when we switch CDs, and optmising the CD<->drive

-=- James Mastros

True mastery is knowing enough to bullshit the rest.
	-=- Me

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to