Messages in this thread | | | Date | Thu, 30 Apr 1998 22:15:52 -0400 (EDT) | From | James Mastros <> | Subject | Re: CDROM jukebox filesystem using autofs |
| |
On 30 Apr 1998, Aaron Passey wrote: > Rik van Riel <H.H.vanRiel@phys.uu.nl> wrote: > > I'm sure I could come up with a disk swapping policy that's somewhat > reasonable. The question is where in the kernel is that multiplexing and > caching most appropriate to do? It seems like the multiplexing could be done > at the block level but it's not clear to me how this device would manifest > itself. Take the case of 2 drives and 3 users. When the third request comes > in, I want to choose one of the 2 mounted disks to eject and leave it in a wait > queue with all operations blocked. When it's time to swap the other disk back > in, ideally it should be able to go into either drive -- not only the one it > was originally removed from. Is this reasonable? 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.
> The caching, it seems, should be implemented at the filesystem level > since we want to be able to control the caching of data and meta-data > separately. It would be nice, for example to cache all of the meta-data > permanently and the data on an LRU basis. 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.
> Well, it seems like often users would only request one or two files off > of a disk which would work very well with a little bit of read-ahead caching. > I imagine the heavily used disks (like the Redhat disk while a company is > upgrading machines) would have almost all of their contents cached on harddisk. > Just using the Linux built in page-cache (although would help things a lot) is > not sufficient for this application. 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>
-=- 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
| |