On Wed, 15 Mar 2000, Eric Lee Green wrote:
> I've discovered that there are three basic types of tape drives:
>
> a) Tape drives that do not support partitions. Most QIC-style drives, DLT.
> b) Tape drives that support two partitions. DAT drives, Ecrix VXA.
> c) Tape drives that support "lots" of partitions (24 or more). Exabyte
> Mammoth, Tandberg MLR/SLR-6 family. Maybe the AIT family (haven't had a
> chance
> to check that yet, but if the Mammoth does it, I'm pretty sure that AIT
> does too).
>
...
> The current 'st.c' driver in linux/drivers/scsi/st.c only understands scheme
> b), the two-partition DAT scheme. It does not understand scheme c) drives that
> support "lots" of partitions. If you try issuing a partitioning command to a
> drive that supports "lots" of partitions, or which supports the standard
> SCSI-3 partitioning stuff out of the T-10 docs, the command fails. This is
> because the 'length' field in SCSI-3 for MODE_SELECT page 0x11 (the Medium
> Partition Page) must be what you read using MODE_SENSE for page 0x11.
> Meanwhile, for DAT drives, the 'length' field must be 6 if you're zapping the
> (second and only other) partition, and 8 if you creating the (second and only
> other) partition.
>
The "current" st.c driver is what is in 2.3.99-pre1 (it seems that you
have looked at the 2.2 driver). The changes from 2.3.52 to 2.3.99-pre1
contain changes to MTMKPART that probably address the problems you
describe (and some other, too). These changes were initiated by
Michael Schaefer and it seems that we have done parallel work. If you have
any problems in the new approach, please let me know. I am intending to
port this new code back to 2.2 after getting enough feedback from 2.3. (If
someone would like to test the 2.3.99-pre1 algorithm but does not want to
use a new kernel, I can make a patch for 2.2 within the next few days.)
The new version is based on the principle that the length of the mode page
read from the drive is used also for writing it back to the drive. With
proper settings in the other fields this seems to work with all of the
drives that the previous one has worked plus many others. The new method
is also compatible with SCSI-3 and Mammoth, SLR, and VXA documentation. I
have not seen any AIT documents.
Basically the st.c driver has a very long time understood more than two
partitions (up to the ST_NBR_PARTITIONS which defaults to 4). It is only
MTMKPART that is limited to two partitions.
...
> For the future:
> The whole 'mkpartition' concept needs a bit of thought before the 2.6
> kernel. It made sense back when the only tape drives that supported partitions
> were DAT drives, and said drives only supported a maximum of two partitions.
> It does not make sense today to have an interface that supports only two
> partitions, when Exabyte Mammoth II drives can have up to 63 additional
> partitions, and Tandberg MLR drives can have up to 35 additional partitions.
>
The new code would be easy to change so that MTMKPART with nonzero
partition adds one more partition but I am not sure if this is necessary
(it would break backward compatibility). If it is found necessary, the
change can be easily made in 2.5 (it breaks aspects of backward
compatibility that no one probably relies on ;-)
There are several other variations of partitioning that are not supported
by MTMKPART. However, I am not sure even that we should even have a
complex MTMKPART. It might be better to have a user space program for
partitioning tapes if the user wants more complex partitioning schemes.
Kai
