Re: CDROM jukebox filesystem using autofs
Sat, 2 May 1998 17:24:54 -0400 (EDT)

On Fri, 1 May 1998, James Mastros wrote:

[snip talk about hugh cd jukebox]
> 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
^^^^^^^^ Whats this?? I dont know about where you are.. but in the US we
have Child Labor laws! Anyways, why would they need them.. They have a
robot arm to autoload! :) :) :)

> 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?)

Actually, here is how it IMHO 'should' be done:

Interface to the real cdroms through the normal scsi crap.. (there were 4
of them as I recall)..

Write a program that acts as a NFS server. It stores files such:
/usr/local/cdthingy/data/index #The merged and sorted directory structure
of the entire array.
/usr/local/cdthingy/data/cache/ #A cache spool

When mounted this thing should provide a single tree for the array..
When the user reads a file, it figures out what disk it's on and loads the
disk (finding a drive described below), then it copys the file (and
perhaps some other files from that disk) to the cache. If the cache is
more then x% of it's maximum defined size then it deletes some of the last
used non open file to bring it down to a low water mark.

If all drives are full it find the drive that hasn't had files copyed for
the longest time and unloads it..

I dont know about this array physiclly, but perhaps the robot could resort
it as it swaps the disks in and out of the drives, thus moving the most
used CDs close to the drives..

If this is acceptible then this thread can move elseware.. This doesn't
need to be in the kernel, this is too array dependent to warrent inclusion

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