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
mapping.
-=- 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 majordomo@vger.rutgers.edu