There are several problems I am running into with this approach. First
of all, what do I do if I have 4 drives, all mounted and busy, and I get a
request for a fifth disk? I can't open a drive and swap disks since they are
all mounted and I can't unmount any of them since they are busy. I really want
to remove a disk from a drive, block all processes requesting data off of that
disk, and put the other disk into the drive to complete the request for the
fifth disk. This, of course, could make a disk swapping nightmare but at least
it would work.
What's the cleanest way to implement this functionality in the kernel?
My first thought is to make block device multiplexer. This device would be
attached to a real block device and would provide any number of multiplexed
block devices to the user. The multiplexed block device can either forward
requests to the real device or block them. This way I could have 2 CDs mounted
on /dev/scd0 through the multiplexer and switch between them as needed. This
sceme, however, does not allow swapping the disk back into a different drive
which would be a very useful feature. Any suggestions?
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. It
seems like this persistent caching should be implemented as a separate entity
in the kernel. This same persistent caching would also be very useful to NFS
and other slow file systems and is already implemented in Coda. Has anyone
done any work on making a CacheFS or possibly persistent caching at the block
level? Is Coda a reasonable starting point to make a generic persistent
caching file system / driver?
Thanks for your help,
Aaron
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu