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?
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.
>For truly high-latency apps this might not be the case.
>Simply make sure that your readahead (on large files) is
>big enough (and maybe HD cached) so that no more than
>50% of the time/bandwidth is spent switching the disks.
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.
Aaron
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu