> On 21.12.2015, at 14.46, Emmanuel Florac <eflorac@xxxxxxxxxxxxxx> wrote: > > Le Fri, 18 Dec 2015 17:06:44 +0100 > Emmanuel Florac <eflorac@xxxxxxxxxxxxxx> écrivait: > >> >> I'm trying to use mt to work with LTO-5 and bigger tapes. Switching >> partitions works: >> >> # tapeinfo -f /dev/sg1 >> Product Type: Tape Drive >> Vendor ID: 'HP ' >> Product ID: 'Ultrium 5-SCSI ' >> Revision: 'Z61U' >> Attached Changer API: No >> SerialNumber: 'HU1249TP88' >> MinBlock: 1 >> MaxBlock: 16777215 >> SCSI ID: 1 >> SCSI LUN: 0 >> Ready: yes >> BufferedMode: yes >> Medium Type: Not Loaded >> Density Code: 0x58 >> BlockSize: 0 >> DataCompEnabled: yes >> DataCompCapable: yes >> DataDeCompEnabled: yes >> CompType: 0x1 >> DeCompType: 0x1 >> BOP: yes >> Block Position: 0 >> Partition 0 Remaining Kbytes: 1459056 >> Partition 0 Size in Kbytes: 1459056 >> ActivePartition: 0 >> EarlyWarningSize: 0 >> NumPartitions: 1 >> MaxPartitions: 1 >> Partition0: 38 >> Partition1: 1453 >> >> # mt -f /dev/nst0 setpartition 1 >> >> >> However "mt mkpartition" fails miserably: >> >> # mt -f /dev/nst0 mkpartition 1453 >> /dev/nst0: Input/output error >> >> # dmesg | tail >> st 6:0:1:0: st0: Failed to read 65536 byte block with 256 byte >> transfer. st0: Sense Key : Illegal Request [current] >> st0: Add. Sense: Invalid field in parameter list >> >> Is this a limitation of mt or the st driver? >> > > I'm replying to myself: this is very obviously a limitation of the st > driver. Checking st.c partition_tape() function, it looks like it only > knows of hardware from past century… > True, it does support only the methods supported by the drives available to the developers at that time :-) However, I am not any more convinced that partitioning a tape should be done by the kernel driver. A more flexible method would be a user space program using sg (or bsg) driver. > OTOH it seems that Cygwin does that properly... by using > CreateTapePartition, a windows kernel32.dll function. Argh. We'll have > to do the heavy lifting of SCSI commands by hand, then. > > Where should we post an eventual patch, given that the linux-tape ML > looks like a ghost town? It would also be great to be able to support > more than 2 partitions (LTO-6 and 7 support 4), but that would require > patching the mt utility too, but I don't where it currently lives :) > Any hints welcome. > This (linux-scsi) is the correct mailing list. The correct source code of your mt depends on the version you are using (check the distribution). Not also that the ioctl method for creating partitions available in the kernel supports only up to two partitions. If you want more, you should design a new interface. Kai -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
