Messages in this thread | | | From | linker@nightsha ... | Date | Sat, 2 May 1998 17:24:54 -0400 (EDT) | Subject | Re: CDROM jukebox filesystem using autofs |
| |
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?) [snip]
Actually, here is how it IMHO 'should' be done:
1) Interface to the real cdroms through the normal scsi crap.. (there were 4 of them as I recall)..
2) 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 anyways..
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |