The new patch did not work for me, but I chatted with Shane and I have his mt
version.
I will update my DAT to same firmware or newer than his and provide a second
tested by.
I also expect my LTO5 to show up this week so will be ready for that.
Thanks everyone for keeping tapes alive
Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services
----- Original Message -----
From: "Kai Mäkisara (Kolumbus)" <kai.makis...@kolumbus.fi>
To: "Shane M Seymour" <shane.seym...@hpe.com>
Cc: "Laurence Oberman" <lober...@redhat.com>, "Emmanuel Florac"
<eflo...@intellique.com>, "Laurence Oberman" <oberma...@gmail.com>,
linux-scsi@vger.kernel.org
Sent: Monday, February 1, 2016 1:43:26 PM
Subject: Re: What partition should the MTMKPART argument specify? Was: Re: st
driver doesn't seem to grok LTO partitioning
> On 1.2.2016, at 8.31, Seymour, Shane M <shane.seym...@hpe.com> wrote:
>
> Hi Kai,
>
> Thanks for the changes the HPE DAT72 DDS5 drive now works as expected:
>
Good. Thanks for testing.
...
>
> I'm asking around again one final time to see if I can lay my hands on a LTO5
> or greater drive so I can test LTO partitioning as well.
>
> The only other thing I can think of (I'm not sure if this is an improvement
> or not) is if bp[pgo + PP_OFF_MAX_ADD_PARTS] + bp[pgo + PP_OFF_NBR_ADD_PARTS]
> (max.parts and nbr_parts in the debug message) is zero just return -EINVAL
> unless you know of any take drives that report them both as 0 but can be
> partitioned? That is after this:
>
> DEBC_printk(STp, "psd_cnt %d, max.parts %d, nbr_parts %d\n",
> psd_cnt, bp[pgo + PP_OFF_MAX_ADD_PARTS],
> bp[pgo + PP_OFF_NBR_ADD_PARTS]);
>
> add (and also turn off the can-partitions option):
>
> if ((bp[pgo + PP_OFF_MAX_ADD_PARTS] + bp[pgo + PP_OFF_NBR_ADD_PARTS])
> == 0) {
> DEBC_printk(STp, "Drive not partitionable - max.parts+nbr_parts
> is 0\n");
> STp->can_partitions = 0;
> return -EINVAL;
> }
>
> I'm not especially fussed if you don't want to add that though.
>
I thought about a test like this (only test maximum number) but decided not to
add it. The reason was that
I did not want to change anything that has worked before. I quite trust that
the current drives return sense
data instead of crashing and the end result for the user would be the same.
However, one can argue that
returning EINVAL is better than EIO but does the user notice? If the common
opinion is that a test like this
should be added, I am not against it. It can be added to the code for SCSI >=3
where it does not risk
anything for the old drives.
IMHO, can_partitions should not be cleared based on the test. For example,
trying to partition a LTO-4 tape
in a LTO-5 drive should not disable partitioning. (The mode page should return
zero as maximum number of
partitions when a LTO-4 tape is inserted.)
Thanks,
Kai
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
