Re: st driver doesn't seem to grok LTO partitioning

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux