> On 21.12.2015, at 19.57, Emmanuel Florac <eflorac@xxxxxxxxxxxxxx> wrote: > > Le Mon, 21 Dec 2015 19:25:27 +0200 > "Kai Mäkisara (Kolumbus)" <kai.makisara@xxxxxxxxxxx> écrivait: > >>> >>> 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. > > Yes, that's the way the LTFS utility works. That makes the code of the > application quite hard to read, though, as partitioning on modern > drives is pretty complex and requires understanding ugly, unholy SCSI > commands magic. Then Windows/Cygwin, IBM AIX and maybe others seem to > implement partitioning at the kernel level. > > Do you suggest the current mkpartition/setpartition scheme should be > removed instead of enhanced ? :) > I don’t suggest that it should be removed. I just pointed out another possibility to implement the more complex formatting cases. I think that SCSI is well defined, but it offers too many ways to do one thing :-) In user space one can implement several alternatives but the kernel driver has to choose only one (or move the complexity to the interface). On the other hand, the kernel driver can allow anyone (who can access the st device) to partition the tape. A user space program needs more rights. If the current interface (MTMKPART) is acceptable, we could enhance the driver so that it handles properly more drives. I looked at the HP Ultrium SCSI reference and it may not be too complicated (for instance, it needs a separate FORMAT MEDIUM command) . I have also found an IBM reference and others can probably be found. I can look at the manuals during Christmas holidays and try to think about a suggestion. All other suggestions are, of course, welcome. My view may be somewhat theoretical because I don’t have access to current hardware. >>> 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. >> > > OK. As I mentioned, the bizarre IBM lin_tape driver (what use is it?) > implements the complete scheme properly apparently, in a nice GPL2 code. > Why they didn't contribute it directly to the st driver is mysterious. > I will look at the driver. HP also seems to have an implementation (for LTFS) but I did not find the code because their web links don’t seem to be uptodate. >> 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. > > I'm using mt-st on debian, the one that seems to go hand in hand with > the st driver. Both carry your copyright :) > OK. Then the mt part will not be a problem. I have not updated it “recently” because the kernel interface has not changed. 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
