>
> I am writing a Linux filesystem / driver for a CDROM jukebox.
[...]
> The second big problem is persistent caching of data and meta-data on
> the CDs. It would be nice to be able to do an 'ls -lR' of the directory tree
> of the jukebox and not thrash the robot around for an hour swapping disks in
> and out of the drives. With proper caching, the efficiency of the system would
> be increased dramatically and wear on the robot would be much reduced.
I've been musing on this issue (ever since I saw a $50 4x4 IDE CDROM
drive). My thought is that while caching is certainly a good idea, a
simple hysteresis technique could at least ameleoriate the thrashing
problem. My basic idea is to only allow disks to be switched (and really
this technique could apply to any jukebox media, not just CDROM drives)
after X amount of data has been transferred, or Y amount of time has
expired -- and every time a switch happens at the X or Y limit, double
that limit. When X or Y passes without a switch request, halve them (back
to the original value as a minimum.) This would mean that tasks competing
for the same resources would quickly cause the multiplexer to give more
and more time/data to each process in turn, thus reducing jukebox
manuevers, saving time & wear, at the cost of more bursty data retrieval.
Obviously this would need some substantial tuning to be safe and
effective. However, it wouldn't help at all with interactive response for
things like file directories, which would seem to be very much worth
caching, even if nothing else is cached. If Coda provides a useful caching
mechanism, it would seem worth considering it as a general mechanism for
the entire project.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu