>> A variant of that might make more sense here - perhaps have the
>> /dev/jukebox (or whatever) as the device number for the entire
>> jukebox array, similar to the RAID devices. One could then have
>> that as a pseudo-directory that has a separate [directory] entry
>> for each available CD similar to the virtual /proc file system's
>> method of 'storing' files...
>> This would mean that a system with two 3-changer drives would
>> appear something like the following listing:
>> The letter would be used internally to identify which drive, and
>> the number that followed would say which disc from that drive: one
>> could easily support MILLIONS of disks that way...
> Hmm... This, I assume, is nearly what the original idea was -- only
> without the letter -- the whole point is that we want to be
> independent of what drive holds what CD, so we can optmise use of
> the drives (IE each drive can hold any CD that you have, so if we
> have 10 drives, the users can use any 10 of the 1,000 avaible CDs).
Not quite what I intended to say then - I would envisage such a driver
being able to handle MULTIPLE multichanger arrays, with each array
having a set of CD's available to that array only.
I don't know what particular make of jukebox you're using, so for
argument's sake, let's assume it's a SUPADUPA A1 unit. Imagine that
you have FOUR such units, all connected to the same computer, each
with its collection of CD's available. It stands to reason that one
would NOT be able to take a CD stored in the first unit and mount it
in the drive in the fourth unit, or so I would assume...
Indeed, the driver would probably make sense implemented as some sort
of superdriver like the current RAID driver is, so it could be told to
take charge of not only the jukebox you envision, but also other
multi-changers, and even CD images stored on the hard disk, or the
like. This would result in TWO drivers, one a fairly simple one that
took direct control of an individual jukebox unit, and mounted a
particular disk in a particular drive when told to do so, the other a
far more 'intelligent' one that kept track of what CD's were mounted
and implemented the mount optimisations...
> However, this dosn't take into account my problem at all -- that
> being that this dosn't allow you to do IO (I, rather, these are
> CD-_RO_Ms) on the raw disk -- only to mount it.
> Instead, how about making the jukeboxfs layout be either of n files
> (where n=the number of avaible CDs), with names of 1 to n (well, 1
> to n, followed by a letter from 'a' to 'q' indicating the
> partition), which you could mount with loopback. Or, you could have
> a set of files like the ones in the last sugestion, only precided
> by 'D' (for device), and internaly "mount" them into directories
> with the same name, only with D replaced by F (filesystem).
Why not use the format used with the hard drives at the moment. Using
the idea of two multichangers with three disks each, and each with two
partitions, with only disk number 1 in the first unit and disk 0 in
the second unit having been mounted so far, the following would appear
reasonable:
Q> $ mount /jukebox
Q> $ ls -lad /jukebox/* | tr -s ' ' | cut -d ' ' -f 1,9-
Q> dr-xr-xr-x a0
Q> dr-xr-xr-x a1
Q> dr-xr-xr-x a1a
Q> dr-xr-xr-x a1b
Q> dr-xr-xr-x a2
Q> dr-xr-xr-x b0
Q> dr-xr-xr-x b0a
Q> dr-xr-xr-x b0b
Q> dr-xr-xr-x b1
Q> dr-xr-xr-x b2
Basically, each available disk would appear with its number when the
unit starts up, but without the subpartition entries, and those would
be added when each disk is first mounted. Also, if any of the drives
are free for any length of time, the driver could mount and unmount
previously unmounted CD's so as to add this information ready for if
that CD gets referenced in the future...
Alternatively, since that would inevitably produce an enormous
directory listing, perhaps the listing could be split up with two or
more levels of directories? Do CD's have volume labels? If so, maybe
those could be made use of, producing something like the following for
the above:
Q> $ mount /jukebox
Q> cd /jukebox
Q> $ ls -lad */* | tr -s ' ' | cut -d ' ' -f 1,9-
Q> lrwxrwxrwx 1/1001_interesting_facts_about_space -> ../cd/b0a
Q> lrwxrwxrwx E/Encyclopaedia_of_Science -> ../cd/a1a
Q> lrwxrwxrwx NA/b0b -> ../b0b
Q> lrwxrwxrwx T/Thesaurus_of_Science -> ../cd/a1b
Q> dr-xr-xr-x cd/a0
Q> dr-xr-xr-x cd/a1
Q> dr-xr-xr-x cd/a1a
Q> dr-xr-xr-x cd/a1b
Q> dr-xr-xr-x cd/a2
Q> dr-xr-xr-x cd/b0
Q> dr-xr-xr-x cd/b0a
Q> dr-xr-xr-x cd/b0b
Q> dr-xr-xr-x cd/b1
Q> dr-xr-xr-x cd/b2
There would be the /jukebox/cd directory which contained a list of the
valid cd's and the identified partitions thereon, and in addition,
there would be a set of directories relating to the volume labels on
the disks that have been mounted, with the name of the directory being
the upper case form of the first letter in the volume name, as shown
above, or the character itself if not a letter, thus reducing the
number of suchlike names to be searched in any individual directory.
For CD's without volume labels, the NA (for "Not Available") directory
would be used for the link, and directories would only appear if there
was at least one volume label in them...
In the above listing, I've assumed long volume labels (probably
unrealistic), and that spaces in the volume label would be translated
to underscores, but that isn't absolutely necessary either...
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu