> On 1.2.2016, at 8.31, Seymour, Shane M <shane.seymour@xxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
