Hello
Finally got my firmware on my DAT updated.
Using Kai's latest patch I validated the patch on my DAT driver as well
Thanks to Shane for providing the correct mt code, as that was also one of my
problems besides firmware.
[root@srp-server mt-st-1.1-patched]# ./mt -f /dev/st0 stsetoption can-partitions
[root@srp-server mt-st-1.1-patched]# ./mt -f /dev/st0 mkpartition 1000
Took almost 6 minutes to partition this old DDS
Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11,
medium 0, WBS 10, BLL 8
Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length:
0, drv buffer: 1
Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer
size: 4096 (1 blocks).
Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] Mode 0 options: buffer
writes: 1, async writes: 1, read ahead: 1
Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] can bsr: 1, two FMs:
0, fast mteom: 0, auto lock: 0,
Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] defs for wr: 0, no
block limits: 0, partitions: 1, s2 log: 0
Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] sysv: 0 nowait: 0
sili: 0 nowait_filemark: 0
Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] debugging: 1
Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] Rewinding tape.
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215
bytes.
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11,
medium 0, WBS 10, BLL 8
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length:
0, drv buffer: 1
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer
size: 4096 (1 blocks).
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Updating partition number
in status.
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Got tape pos. blk 0 part 0.
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Loading tape.
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Error: 8000002, cmd: 0 0 0
0 0 0
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Sense Key : Unit Attention
[current]
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Add. Sense: Not ready to
ready change, medium may have changed
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215
bytes.
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11,
medium 0, WBS 10, BLL 8
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length:
0, drv buffer: 1
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer
size: 4096 (1 blocks).
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Partition page length is
10 bytes.
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] PP: max 1, add 0, xdp 0,
psum 02, pofmetc 0, rec 03, units 00, sizes: 0 65535
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] MP: 11 08 01 00 10 03 00
00 00 00 ff ff
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] psd_cnt 1, max.parts 1,
nbr_parts 0
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Formatting tape with two
partitions (1 = 1000 MB).
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Sent partition page length
is 10 bytes. needs_format: 0
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] PP: max 1, add 1, xdp 1,
psum 02, pofmetc 0, rec 03, units 00, sizes: 1000 65535
Feb 02 22:31:45 srp-server kernel: st 6:0:1:0: [st0] Rewinding tape.
I will retest with Shane's latest additions he just sent after first testing
with Kai's latest patch on my LTO5.
(here's hoping I dont have to update the f/w on that one)
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
