st driver doesn't seem to grok LTO partitioning

Commit Message

Kai Mäkisara (Kolumbus) Jan. 4, 2016, 10:22 a.m. UTC

On Thursday 2015-12-31 18:08, "Kai Mäkisara (Kolumbus)" wrote:

...
>In the HP LTFS sources I found an interesting detail: the code does LOAD before unformatting.
>A comment says that it is in some cases better method to put the position to beginning of
>partition 0 than other methods. You could try ‘mt load’ before trying to partition.
>
Here is again a new version of the patch. This does load before 
partitioning. The code performing default partitioning (FDP=1) has also 
been slightly modified (two more bits of the original mode page 
retained).

The patch has been tested with my DDS-4 drive.

Kai
---------------------------------8<----------------------------------------

Comments

Emmanuel Florac Jan. 4, 2016, 10:54 a.m. UTC | #1

Le Mon, 4 Jan 2016 12:22:34 +0200 (EET)
Kai Makisara <[e-mail]> écrivait:

> >In the HP LTFS sources I found an interesting detail: the code does
> >LOAD before unformatting. A comment says that it is in some cases
> >better method to put the position to beginning of partition 0 than
> >other methods. You could try ‘mt load’ before trying to partition.
> >  
> Here is again a new version of the patch. This does load before 
> partitioning. The code performing default partitioning (FDP=1) has
> also been slightly modified (two more bits of the original mode page 
> retained).

OK, I'll test 'mt load' first, then the new patch. Stay tuned...

Emmanuel Florac Jan. 4, 2016, 11:05 a.m. UTC | #2

Le Mon, 4 Jan 2016 12:22:34 +0200 (EET)
Kai Makisara <[e-mail]> écrivait:

> >In the HP LTFS sources I found an interesting detail: the code does
> >LOAD before unformatting. A comment says that it is in some cases
> >better method to put the position to beginning of partition 0 than
> >other methods. You could try ‘mt load’ before trying to partition.
> >  
> Here is again a new version of the patch. This does load before 
> partitioning. The code performing default partitioning (FDP=1) has
> also been slightly modified (two more bits of the original mode page 
> retained).

You were right, it works by sending a "LOAD" first:

First, not working:

# mt -f /dev/nst0 mkpartition 0

Jan  4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1
Jan  4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape.
Jan  4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: Partition page length is 16 bytes.
Jan  4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 2543 38
Jan  4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: Sending FORMAT MEDIUM
Jan  4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: Error: 8000002, cmd: 4 0 0 0 0 0
Jan  4 12:02:17 shakuhachi kernel: st0: Sense Key : Illegal Request [current] 
Jan  4 12:02:17 shakuhachi kernel: st0: Add. Sense: Position past beginning of medium

Then:

# mt -f /dev/nst0 load

Jan  4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1
Jan  4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Loading tape.
Jan  4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1
Jan  4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).

# mt -f /dev/nst0 mkpartition 0


Jan  4 12:02:42 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  4 12:02:42 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  4 12:02:42 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1
Jan  4 12:02:42 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  4 12:02:42 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape.
Jan  4 12:02:42 shakuhachi kernel: st 7:0:0:0: st0: Partition page length is 16 bytes.
Jan  4 12:02:42 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 2543 38
Jan  4 12:02:42 shakuhachi kernel: st 7:0:0:0: st0: Sending FORMAT MEDIUM

# tapeinfo -f /dev/sg6
Product Type: Tape Drive
Vendor ID: 'HP      '
Product ID: 'Ultrium 6-SCSI  '
Revision: '329U'
Attached Changer API: No
SerialNumber: 'HU1302U4RC'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 0
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x5a
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 3

Emmanuel Florac Jan. 4, 2016, 11:46 a.m. UTC | #3

Le Mon, 4 Jan 2016 12:22:34 +0200 (EET)
Kai Makisara <[e-mail]> écrivait:

> Here is again a new version of the patch. This does load before 
> partitioning. The code performing default partitioning (FDP=1) has
> also been slightly modified (two more bits of the original mode page 
> retained).
> 
> The patch has been tested with my DDS-4 drive.

That works fine for me. I'm going to do some testing with other drives
I have (LTO-3 -- should fail -- and LTO-5).

# modprobe st

Jan  4 12:31:53 shakuhachi kernel: st: Version 20160104, fixed bufsize 32768, s/g segs 256
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: Attached scsi tape st0
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: try direct i/o: yes (alignment 512 B)
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).


# mt -f /dev/st0  stsetoption debug

Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0: Mode 0 options: buffer writes: 1, async writes: 1, read ahead: 1
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0:     can bsr: 1, two FMs: 0, fast mteom: 0, auto lock: 0,
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0:     defs for wr: 0, no block limits: 0, partitions: 0, s2 log: 0
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0:     sysv: 0 nowait: 0 sili: 0 nowait_filemark: 0
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0:     debugging: 1
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape.

# mt -f /dev/st0  stsetoption can-partitions


Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0: Mode 0 options: buffer writes: 1, async writes: 1, read ahead: 1
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0:     can bsr: 1, two FMs: 0, fast mteom: 0, auto lock: 0,
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0:     defs for wr: 0, no block limits: 0, partitions: 1, s2 log: 0
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0:     sysv: 0 nowait: 0 sili: 0 nowait_filemark: 0
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0:     debugging: 1
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape.

# mt -f /dev/nst0  mkpartition 1


Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Updating partition number in status.
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Got tape pos. blk 0 part 0.
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Loading tape.
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Partition page length is 16 bytes.
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 0, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 2620 0
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: MP: 11 0e 03 00 3c 03 09 00 0a 3c 00 00
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: psd_cnt 2, max.parts 3, nbr_parts 0
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Formatting tape with two partitions (FDP).
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Sent partition page length is 12 bytes. needs_format: 1
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 4, psum 03, pofmetc 4, rec 03, units 00, sizes: 65535 0
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: MP: 11 0a 03 01 9c 03 00 00 ff ff 00 00
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Sending FORMAT MEDIUM


# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x5a (no translation).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

Jan  4 12:40:28 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  4 12:40:28 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  4 12:40:28 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1
Jan  4 12:40:28 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).

# mt -f /dev/nst0 setpartition 1
# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=1.
Tape block size 0 bytes. Density code 0x5a (no translation).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

# mt -f /dev/nst0 mkpartition 0


Jan  4 12:42:15 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  4 12:42:15 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  4 12:42:15 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1
Jan  4 12:42:15 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  4 12:42:15 shakuhachi kernel: st 7:0:0:0: st0: Loading tape.
Jan  4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1
Jan  4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Partition page length is 16 bytes.
Jan  4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 2543 38
Jan  4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: MP: 11 0e 03 01 3c 03 09 00 09 ef 00 26
Jan  4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Sending FORMAT MEDIUM

# tapeinfo -f /dev/sg6
Product Type: Tape Drive
Vendor ID: 'HP      '
Product ID: 'Ultrium 6-SCSI  '
Revision: '329U'
Attached Changer API: No
SerialNumber: 'HU1302U4RC'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 0
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x5a
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 3

Emmanuel Florac Jan. 4, 2016, 3:32 p.m. UTC | #4

Le Mon, 4 Jan 2016 10:08:44 -0500
Laurence Oberman <[e-mail]> écrivait:

> I am back at work with access to my tape changer today. Will pull the
> patches and help test as well.
> I assume I need to apply both patches, the earlier one and this
> latest one.
> 

No only the latest one.

Laurence Oberman Jan. 5, 2016, 9:55 p.m. UTC | #5

Testing the patch here in the lab, it seems my firmware will need to be updated to support more than 1 partition.
Looking into that now.

[  193.647807] st: Version 20160104, fixed bufsize 32768, s/g segs 256
[  193.648992] st: Debugging enabled debug_flag = 1
[  193.650907] st 0:0:0:0: Attached scsi tape st0
[  193.652046] st 0:0:0:0: st0: try direct i/o: yes (alignment 4 B)

[  280.069260] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
[  280.070543] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[  280.073068] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
[  280.073725] st 0:0:0:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).

 mt -f /dev/st0  stsetoption can-partitions

[  676.835972] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
[  676.837403] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[  676.838404] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
[  676.838880] st 0:0:0:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
[  676.840383] st 0:0:0:0: [st0] Mode 0 options: buffer writes: 1, async writes: 1, read ahead: 1
[  676.840880] st 0:0:0:0: [st0]     can bsr: 1, two FMs: 0, fast mteom: 0, auto lock: 0,
[  676.842424] st 0:0:0:0: [st0]     defs for wr: 0, no block limits: 0, partitions: 1, s2 log: 0
[  676.842937] st 0:0:0:0: [st0]     sysv: 0 nowait: 0 sili: 0 nowait_filemark: 0
[  676.844524] st 0:0:0:0: [st0]     debugging: 1
[  676.845042] st 0:0:0:0: [st0] Rewinding tape.

mt -f /dev/nst0  mkpartition 1

[  798.711408] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
[  798.712799] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[  798.713948] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
[  798.714504] st 0:0:0:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
[  798.716227] st 0:0:0:0: [st0] Loading tape.
[  798.731230] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
[  798.732874] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[  798.734269] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
[  798.734971] st 0:0:0:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
[  798.737572] st 0:0:0:0: [st0] Partition page length is 10 bytes.
[  798.739162] st 0:0:0:0: [st0] PP: max 0, add 0, xdp 0, psum 03, pofmetc 0,rec 03, units 09, sizes: 1541 65535
[  798.739974] st 0:0:0:0: [st0] MP: 11 08 00 00 18 03 09 00 06 05 ff ff
[  798.740810] st 0:0:0:0: [st0] psd_cnt 2, max.parts 0, nbr_parts 0
[  798.744194] st 0:0:0:0: [st0] Formatting tape with two partitions (FDP).
[  798.745045] st 0:0:0:0: [st0] Sent partition page length is 12 bytes.  needs_format: 0
[  798.747718] st 0:0:0:0: [st0] PP: max 0, add 1, xdp 4, psum 03, pofmetc 0 rec 03, units 00, sizes: 65535 65535
[  798.748558] st 0:0:0:0: [st0] MP: 11 0a 00 01 98 03 00 00 ff ff ff ff
[  798.752622] st 0:0:0:0: [st0] Error: 8000002, cmd: 15 10 0 0 18 0
[  798.753465] st 0:0:0:0: [st0] Sense Key : Illegal Request [current] 
[  798.754289] st 0:0:0:0: [st0] Add. Sense: Invalid field in parameter list
[  798.757546] st 0:0:0:0: [st0] Partitioning of tape failed.



Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services


From: Emmanuel Florac <[e-mail]>
Date: Mon, Jan 4, 2016 at 6:46 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning
To: Kai Makisara <[e-mail]>
Cc: [e-mail]


Le Mon, 4 Jan 2016 12:22:34 +0200 (EET)
Kai Makisara <[e-mail]> écrivait:

> Here is again a new version of the patch. This does load before
> partitioning. The code performing default partitioning (FDP=1) has
> also been slightly modified (two more bits of the original mode page
> retained).
>
> The patch has been tested with my DDS-4 drive.

That works fine for me. I'm going to do some testing with other drives
I have (LTO-3 -- should fail -- and LTO-5).

# modprobe st

Jan  4 12:31:53 shakuhachi kernel: st: Version 20160104, fixed bufsize
32768, s/g segs 256
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: Attached scsi tape st0
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: try direct i/o: yes
(alignment 512 B)
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 -
16777215 bytes.
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11,
medium 0, WBS 10, BLL 8
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape
length: 0, drv buffer: 1
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer
size: 4096 (1 blocks).
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 -
16777215 bytes.
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11,
medium 0, WBS 10, BLL 8
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape
length: 0, drv buffer: 1
Jan  4 12:31:53 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer
size: 4096 (1 blocks).


# mt -f /dev/st0  stsetoption debug

Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 -
16777215 bytes.
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11,
medium 0, WBS 10, BLL 8
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape
length: 0, drv buffer: 1
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer
size: 4096 (1 blocks).
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0: Mode 0 options: buffer
writes: 1, async writes: 1, read ahead: 1
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0:     can bsr: 1, two
FMs: 0, fast mteom: 0, auto lock: 0,
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0:     defs for wr: 0, no
block limits: 0, partitions: 0, s2 log: 0
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0:     sysv: 0 nowait: 0
sili: 0 nowait_filemark: 0
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0:     debugging: 1
Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape.

# mt -f /dev/st0  stsetoption can-partitions


Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 -
16777215 bytes.
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11,
medium 0, WBS 10, BLL 8
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape
length: 0, drv buffer: 1
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer
size: 4096 (1 blocks).
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0: Mode 0 options: buffer
writes: 1, async writes: 1, read ahead: 1
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0:     can bsr: 1, two
FMs: 0, fast mteom: 0, auto lock: 0,
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0:     defs for wr: 0, no
block limits: 0, partitions: 1, s2 log: 0
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0:     sysv: 0 nowait: 0
sili: 0 nowait_filemark: 0
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0:     debugging: 1
Jan  4 12:39:38 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape.

# mt -f /dev/nst0  mkpartition 1


Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 -
16777215 bytes.
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11,
medium 0, WBS 10, BLL 8
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape
length: 0, drv buffer: 1
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer
size: 4096 (1 blocks).
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Updating partition
number in status.
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Got tape pos. blk 0
part 0.
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Loading tape.
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 -
16777215 bytes.
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11,
medium 0, WBS 10, BLL 8
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape
length: 0, drv buffer: 1
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer
size: 4096 (1 blocks).
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Partition page length
is 16 bytes.
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 0, xdp
1, psum 03, pofmetc 4, rec 03, units 09, sizes: 2620 0
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: MP: 11 0e 03 00 3c 03
09 00 0a 3c 00 00
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: psd_cnt 2, max.parts 3,
nbr_parts 0
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Formatting tape with
two partitions (FDP).
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Sent partition page
length is 12 bytes. needs_format: 1
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp
4, psum 03, pofmetc 4, rec 03, units 00, sizes: 65535 0
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: MP: 11 0a 03 01 9c 03
00 00 ff ff 00 00
Jan  4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Sending FORMAT MEDIUM


# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x5a (no translation).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

Jan  4 12:40:28 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 -
16777215 bytes.
Jan  4 12:40:28 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11,
medium 0, WBS 10, BLL 8
Jan  4 12:40:28 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape
length: 0, drv buffer: 1
Jan  4 12:40:28 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer
size: 4096 (1 blocks).

# mt -f /dev/nst0 setpartition 1
# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=1.
Tape block size 0 bytes. Density code 0x5a (no translation).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

# mt -f /dev/nst0 mkpartition 0


Jan  4 12:42:15 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 -
16777215 bytes.
Jan  4 12:42:15 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11,
medium 0, WBS 10, BLL 8
Jan  4 12:42:15 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape
length: 0, drv buffer: 1
Jan  4 12:42:15 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer
size: 4096 (1 blocks).
Jan  4 12:42:15 shakuhachi kernel: st 7:0:0:0: st0: Loading tape.
Jan  4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 -
16777215 bytes.
Jan  4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11,
medium 0, WBS 10, BLL 8
Jan  4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape
length: 0, drv buffer: 1
Jan  4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer
size: 4096 (1 blocks).
Jan  4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Partition page length
is 16 bytes.
Jan  4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp
1, psum 03, pofmetc 4, rec 03, units 09, sizes: 2543 38
Jan  4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: MP: 11 0e 03 01 3c 03
09 00 09 ef 00 26
Jan  4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Sending FORMAT MEDIUM

# tapeinfo -f /dev/sg6
Product Type: Tape Drive
Vendor ID: 'HP      '
Product ID: 'Ultrium 6-SCSI  '
Revision: '329U'
Attached Changer API: No
SerialNumber: 'HU1302U4RC'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 0
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x5a
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 3



--
------------------------------------------------------------------------
Emmanuel Florac     |   Direction technique
                    |   Intellique
                    |   <[e-mail]>
                    |   [phone]
------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Emmanuel Florac Jan. 6, 2016, 3:10 p.m. UTC | #6

Le Tue, 5 Jan 2016 16:55:04 -0500 (EST)
Laurence Oberman <[e-mail]> écrivait:

> mt -f /dev/nst0  mkpartition 1
> 

What is the type of drive exactly? I still couldn't test with the LTO-5
drive as the machine it's connected to is being reinstalled.

Laurence Oberman Jan. 6, 2016, 3:23 p.m. UTC | #7

Hello Emanuel

I am using this device, its an Ultrium 5 (LTO5)
Its an older changer and I am unable to update the firmware, still working on that.

What version of mt are you using, as I am testing using a RHEL7.2 base and the upstream patched kernel.

Linux example.redhat.com 4.3.3 #1 SMP Tue Jan 5 15:58:47 EST 2016 x86_64 x86_64 x86_64 GNU/Linux

# tapeinfo -f /dev/st0
Product Type: Tape Drive
Vendor ID: 'QUANTUM '
Product ID: 'ULTRIUM 5       '
Revision: '3060'
Attached Changer API: No
SerialNumber: 'HU1023AKHE'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 0
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x58
BlockSize: 512
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
Partition 0 Remaining Kbytes: 1541692
Partition 0 Size in Kbytes: 1541692
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 0

Drive is working fine,

# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x58 (no translation).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

This is what I get when I try and partition and I believe this may be a firmware issue for me.

mt -f /dev/st0  stsetoption can-partitions

[ 5343.620005] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
[ 5343.621424] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 5343.622005] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
[ 5343.622606] st 0:0:0:0: [st0] Block size: 512, buffer size: 4096 (8 blocks).
[ 5343.623208] st 0:0:0:0: [st0] Mode 0 options: buffer writes: 1, async writes: 1, read ahead: 1
[ 5343.623810] st 0:0:0:0: [st0]     can bsr: 1, two FMs: 0, fast mteom: 0, auto lock: 0,
[ 5343.624413] st 0:0:0:0: [st0]     defs for wr: 0, no block limits: 0, partitions: 1, s2 log: 0
[ 5343.625011] st 0:0:0:0: [st0]     sysv: 0 nowait: 0 sili: 0 nowait_filemark: 0
[ 5343.625623] st 0:0:0:0: [st0]     debugging: 1
[ 5343.626222] st 0:0:0:0: [st0] Rewinding tape.

# mt -f /dev/nst0  mkpartition 1
/dev/nst0: Input/output error





Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

----- Original Message -----
From: "Emmanuel Florac" <[e-mail]>
To: "Laurence Oberman" <[e-mail]>
Cc: "Laurence Oberman" <[e-mail]>, "Kai Makisara" <[e-mail]>, [e-mail]
Sent: Wednesday, January 6, 2016 10:10:49 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning

Le Tue, 5 Jan 2016 16:55:04 -0500 (EST)
Laurence Oberman <[e-mail]> écrivait:

> mt -f /dev/nst0  mkpartition 1
> 

What is the type of drive exactly? I still couldn't test with the LTO-5
drive as the machine it's connected to is being reinstalled.

Laurence Oberman Jan. 6, 2016, 3:25 p.m. UTC | #8

I left the log of the failure to partition out

Here it is

# mt -f /dev/nst0  mkpartition 1
/dev/nst0: Input/output error

[ 5499.341648] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
[ 5499.342903] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 5499.343523] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
[ 5499.344114] st 0:0:0:0: [st0] Block size: 512, buffer size: 4096 (8 blocks).
[ 5499.344702] st 0:0:0:0: [st0] Loading tape.
[ 5499.359733] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
[ 5499.360970] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 5499.361584] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
[ 5499.362165] st 0:0:0:0: [st0] Block size: 512, buffer size: 4096 (8 blocks).
[ 5499.363851] st 0:0:0:0: [st0] Partition page length is 10 bytes.
[ 5499.364468] st 0:0:0:0: [st0] PP: max 0, add 0, xdp 0, psum 03, pofmetc 0,rec 03, units 09, sizes: 1541 65535
[ 5499.365074] st 0:0:0:0: [st0] MP: 11 08 00 00 18 03 09 00 06 05 ff ff
[ 5499.365658] st 0:0:0:0: [st0] psd_cnt 2, max.parts 0, nbr_parts 0
[ 5499.366246] st 0:0:0:0: [st0] Formatting tape with two partitions (FDP).
[ 5499.366826] st 0:0:0:0: [st0] Sent partition page length is 12 bytes.  needs_format: 0
[ 5499.367424] st 0:0:0:0: [st0] PP: max 0, add 1, xdp 4, psum 03, pofmetc 0 rec 03, units 00, sizes: 65535 65535
[ 5499.368024] st 0:0:0:0: [st0] MP: 11 0a 00 01 98 03 00 00 ff ff ff ff
[ 5499.369842] st 0:0:0:0: [st0] Error: 8000002, cmd: 15 10 0 0 18 0
[ 5499.370495] st 0:0:0:0: [st0] Sense Key : Illegal Request [current] 
[ 5499.371109] st 0:0:0:0: [st0] Add. Sense: Invalid field in parameter list
[ 5499.371714] st 0:0:0:0: [st0] Partitioning of tape failed.

Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

----- Original Message -----
From: "Laurence Oberman" <[e-mail]>
To: "Emmanuel Florac" <[e-mail]>
Cc: "Laurence Oberman" <[e-mail]>, "Kai Makisara" <[e-mail]>, [e-mail]
Sent: Wednesday, January 6, 2016 10:23:34 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning

Hello Emanuel

I am using this device, its an Ultrium 5 (LTO5)
Its an older changer and I am unable to update the firmware, still working on that.

What version of mt are you using, as I am testing using a RHEL7.2 base and the upstream patched kernel.

Linux example.redhat.com 4.3.3 #1 SMP Tue Jan 5 15:58:47 EST 2016 x86_64 x86_64 x86_64 GNU/Linux

# tapeinfo -f /dev/st0
Product Type: Tape Drive
Vendor ID: 'QUANTUM '
Product ID: 'ULTRIUM 5       '
Revision: '3060'
Attached Changer API: No
SerialNumber: 'HU1023AKHE'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 0
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x58
BlockSize: 512
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
Partition 0 Remaining Kbytes: 1541692
Partition 0 Size in Kbytes: 1541692
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 0

Drive is working fine,

# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x58 (no translation).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

This is what I get when I try and partition and I believe this may be a firmware issue for me.

mt -f /dev/st0  stsetoption can-partitions

[ 5343.620005] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
[ 5343.621424] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 5343.622005] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
[ 5343.622606] st 0:0:0:0: [st0] Block size: 512, buffer size: 4096 (8 blocks).
[ 5343.623208] st 0:0:0:0: [st0] Mode 0 options: buffer writes: 1, async writes: 1, read ahead: 1
[ 5343.623810] st 0:0:0:0: [st0]     can bsr: 1, two FMs: 0, fast mteom: 0, auto lock: 0,
[ 5343.624413] st 0:0:0:0: [st0]     defs for wr: 0, no block limits: 0, partitions: 1, s2 log: 0
[ 5343.625011] st 0:0:0:0: [st0]     sysv: 0 nowait: 0 sili: 0 nowait_filemark: 0
[ 5343.625623] st 0:0:0:0: [st0]     debugging: 1
[ 5343.626222] st 0:0:0:0: [st0] Rewinding tape.

# mt -f /dev/nst0  mkpartition 1
/dev/nst0: Input/output error





Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

----- Original Message -----
From: "Emmanuel Florac" <[e-mail]>
To: "Laurence Oberman" <[e-mail]>
Cc: "Laurence Oberman" <[e-mail]>, "Kai Makisara" <[e-mail]>, [e-mail]
Sent: Wednesday, January 6, 2016 10:10:49 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning

Le Tue, 5 Jan 2016 16:55:04 -0500 (EST)
Laurence Oberman <[e-mail]> écrivait:

> mt -f /dev/nst0  mkpartition 1
> 

What is the type of drive exactly? I still couldn't test with the LTO-5
drive as the machine it's connected to is being reinstalled.

Laurence Oberman Jan. 6, 2016, 3:32 p.m. UTC | #9

Firmware update fails as follows:

Still researching. This is the only LTO5 I have access to so unless Shane has one I may not be able to make progress.
(Its way long out of warranty and support)

We mostly use this for generic st driver and changer testing for RHEL and it has not been updated for at least two years.

Performing FUP operation...

Checking image file (/root/V3210A011-E00.IMG)

Checking device readiness

Sending image file to the device

Redetecting device
Fup drive command failed: Unknown error! (status = -100)

Host adapter status = 0x00
Driver status = 0x08
Error buffer = 'MSG: FupDrive() - Error committing image file to drive (/root/V3210A011-E00.IMG) 1584236 of 1584236 bytes written.
SCSI: WriteBuffer()::DevIo() - ErrorCode (0x70h) ,Sense Key (0x05h) ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST. ASC(0x26h), ASCQ(0x00h) - )
'

Unable to perform FUP operation.


Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

----- Original Message -----
From: "Laurence Oberman" <[e-mail]>
To: "Emmanuel Florac" <[e-mail]>
Cc: "Laurence Oberman" <[e-mail]>, "Kai Makisara" <[e-mail]>, [e-mail]
Sent: Wednesday, January 6, 2016 10:25:37 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning

I left the log of the failure to partition out

Here it is

# mt -f /dev/nst0  mkpartition 1
/dev/nst0: Input/output error

[ 5499.341648] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
[ 5499.342903] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 5499.343523] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
[ 5499.344114] st 0:0:0:0: [st0] Block size: 512, buffer size: 4096 (8 blocks).
[ 5499.344702] st 0:0:0:0: [st0] Loading tape.
[ 5499.359733] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
[ 5499.360970] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 5499.361584] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
[ 5499.362165] st 0:0:0:0: [st0] Block size: 512, buffer size: 4096 (8 blocks).
[ 5499.363851] st 0:0:0:0: [st0] Partition page length is 10 bytes.
[ 5499.364468] st 0:0:0:0: [st0] PP: max 0, add 0, xdp 0, psum 03, pofmetc 0,rec 03, units 09, sizes: 1541 65535
[ 5499.365074] st 0:0:0:0: [st0] MP: 11 08 00 00 18 03 09 00 06 05 ff ff
[ 5499.365658] st 0:0:0:0: [st0] psd_cnt 2, max.parts 0, nbr_parts 0
[ 5499.366246] st 0:0:0:0: [st0] Formatting tape with two partitions (FDP).
[ 5499.366826] st 0:0:0:0: [st0] Sent partition page length is 12 bytes.  needs_format: 0
[ 5499.367424] st 0:0:0:0: [st0] PP: max 0, add 1, xdp 4, psum 03, pofmetc 0 rec 03, units 00, sizes: 65535 65535
[ 5499.368024] st 0:0:0:0: [st0] MP: 11 0a 00 01 98 03 00 00 ff ff ff ff
[ 5499.369842] st 0:0:0:0: [st0] Error: 8000002, cmd: 15 10 0 0 18 0
[ 5499.370495] st 0:0:0:0: [st0] Sense Key : Illegal Request [current] 
[ 5499.371109] st 0:0:0:0: [st0] Add. Sense: Invalid field in parameter list
[ 5499.371714] st 0:0:0:0: [st0] Partitioning of tape failed.

Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

----- Original Message -----
From: "Laurence Oberman" <[e-mail]>
To: "Emmanuel Florac" <[e-mail]>
Cc: "Laurence Oberman" <[e-mail]>, "Kai Makisara" <[e-mail]>, [e-mail]
Sent: Wednesday, January 6, 2016 10:23:34 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning

Hello Emanuel

I am using this device, its an Ultrium 5 (LTO5)
Its an older changer and I am unable to update the firmware, still working on that.

What version of mt are you using, as I am testing using a RHEL7.2 base and the upstream patched kernel.

Linux example.redhat.com 4.3.3 #1 SMP Tue Jan 5 15:58:47 EST 2016 x86_64 x86_64 x86_64 GNU/Linux

# tapeinfo -f /dev/st0
Product Type: Tape Drive
Vendor ID: 'QUANTUM '
Product ID: 'ULTRIUM 5       '
Revision: '3060'
Attached Changer API: No
SerialNumber: 'HU1023AKHE'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 0
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x58
BlockSize: 512
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
Partition 0 Remaining Kbytes: 1541692
Partition 0 Size in Kbytes: 1541692
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 0

Drive is working fine,

# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x58 (no translation).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

This is what I get when I try and partition and I believe this may be a firmware issue for me.

mt -f /dev/st0  stsetoption can-partitions

[ 5343.620005] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
[ 5343.621424] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 5343.622005] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
[ 5343.622606] st 0:0:0:0: [st0] Block size: 512, buffer size: 4096 (8 blocks).
[ 5343.623208] st 0:0:0:0: [st0] Mode 0 options: buffer writes: 1, async writes: 1, read ahead: 1
[ 5343.623810] st 0:0:0:0: [st0]     can bsr: 1, two FMs: 0, fast mteom: 0, auto lock: 0,
[ 5343.624413] st 0:0:0:0: [st0]     defs for wr: 0, no block limits: 0, partitions: 1, s2 log: 0
[ 5343.625011] st 0:0:0:0: [st0]     sysv: 0 nowait: 0 sili: 0 nowait_filemark: 0
[ 5343.625623] st 0:0:0:0: [st0]     debugging: 1
[ 5343.626222] st 0:0:0:0: [st0] Rewinding tape.

# mt -f /dev/nst0  mkpartition 1
/dev/nst0: Input/output error





Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

----- Original Message -----
From: "Emmanuel Florac" <[e-mail]>
To: "Laurence Oberman" <[e-mail]>
Cc: "Laurence Oberman" <[e-mail]>, "Kai Makisara" <[e-mail]>, [e-mail]
Sent: Wednesday, January 6, 2016 10:10:49 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning

Le Tue, 5 Jan 2016 16:55:04 -0500 (EST)
Laurence Oberman <[e-mail]> écrivait:

> mt -f /dev/nst0  mkpartition 1
> 

What is the type of drive exactly? I still couldn't test with the LTO-5
drive as the machine it's connected to is being reinstalled.

Douglas Gilbert Jan. 6, 2016, 3:48 p.m. UTC | #10

On 16-01-06 10:32 AM, Laurence Oberman wrote:
> Firmware update fails as follows:
>
> Still researching. This is the only LTO5 I have access to so unless Shane has one I may not be able to make progress.
> (Its way long out of warranty and support)
>
> We mostly use this for generic st driver and changer testing for RHEL and it has not been updated for at least two years.
>
> Performing FUP operation...
>
> Checking image file (/root/V3210A011-E00.IMG)
>
> Checking device readiness
>
> Sending image file to the device
>
> Redetecting device
> Fup drive command failed: Unknown error! (status = -100)
>
> Host adapter status = 0x00
> Driver status = 0x08
> Error buffer = 'MSG: FupDrive() - Error committing image file to drive (/root/V3210A011-E00.IMG) 1584236 of 1584236 bytes written.
> SCSI: WriteBuffer()::DevIo() - ErrorCode (0x70h) ,Sense Key (0x05h) ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST. ASC(0x26h), ASCQ(0x00h) - )
> '
>
> Unable to perform FUP operation.

The 1584236 byte firmware image might be too big for a single
WRITE BUFFER command. You might try getting a recent version of
sg3_utils and doing something like:
    sg_write_buffer -b 4k -I V3210A011-E00.IMG -m 7 /dev/sg3

where /dev/sg3 corresponds to your tape drive. 'lsscsi -g' will
show you the mapping.

The above technique works fine for recent Seagate SAS disks (with
".LOD" firmware images).

Doug Gilbert

> ----- Original Message -----
> From: "Laurence Oberman" <[e-mail]>
> To: "Emmanuel Florac" <[e-mail]>
> Cc: "Laurence Oberman" <[e-mail]>, "Kai Makisara" <[e-mail]>, [e-mail]
> Sent: Wednesday, January 6, 2016 10:25:37 AM
> Subject: Re: st driver doesn't seem to grok LTO partitioning
>
> I left the log of the failure to partition out
>
> Here it is
>
> # mt -f /dev/nst0  mkpartition 1
> /dev/nst0: Input/output error
>
> [ 5499.341648] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
> [ 5499.342903] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
> [ 5499.343523] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
> [ 5499.344114] st 0:0:0:0: [st0] Block size: 512, buffer size: 4096 (8 blocks).
> [ 5499.344702] st 0:0:0:0: [st0] Loading tape.
> [ 5499.359733] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
> [ 5499.360970] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
> [ 5499.361584] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
> [ 5499.362165] st 0:0:0:0: [st0] Block size: 512, buffer size: 4096 (8 blocks).
> [ 5499.363851] st 0:0:0:0: [st0] Partition page length is 10 bytes.
> [ 5499.364468] st 0:0:0:0: [st0] PP: max 0, add 0, xdp 0, psum 03, pofmetc 0,rec 03, units 09, sizes: 1541 65535
> [ 5499.365074] st 0:0:0:0: [st0] MP: 11 08 00 00 18 03 09 00 06 05 ff ff
> [ 5499.365658] st 0:0:0:0: [st0] psd_cnt 2, max.parts 0, nbr_parts 0
> [ 5499.366246] st 0:0:0:0: [st0] Formatting tape with two partitions (FDP).
> [ 5499.366826] st 0:0:0:0: [st0] Sent partition page length is 12 bytes.  needs_format: 0
> [ 5499.367424] st 0:0:0:0: [st0] PP: max 0, add 1, xdp 4, psum 03, pofmetc 0 rec 03, units 00, sizes: 65535 65535
> [ 5499.368024] st 0:0:0:0: [st0] MP: 11 0a 00 01 98 03 00 00 ff ff ff ff
> [ 5499.369842] st 0:0:0:0: [st0] Error: 8000002, cmd: 15 10 0 0 18 0
> [ 5499.370495] st 0:0:0:0: [st0] Sense Key : Illegal Request [current]
> [ 5499.371109] st 0:0:0:0: [st0] Add. Sense: Invalid field in parameter list
> [ 5499.371714] st 0:0:0:0: [st0] Partitioning of tape failed.
>
> Laurence Oberman
> Principal Software Maintenance Engineer
> Red Hat Global Support Services
>
> ----- Original Message -----
> From: "Laurence Oberman" <[e-mail]>
> To: "Emmanuel Florac" <[e-mail]>
> Cc: "Laurence Oberman" <[e-mail]>, "Kai Makisara" <[e-mail]>, [e-mail]
> Sent: Wednesday, January 6, 2016 10:23:34 AM
> Subject: Re: st driver doesn't seem to grok LTO partitioning
>
> Hello Emanuel
>
> I am using this device, its an Ultrium 5 (LTO5)
> Its an older changer and I am unable to update the firmware, still working on that.
>
> What version of mt are you using, as I am testing using a RHEL7.2 base and the upstream patched kernel.
>
> Linux example.redhat.com 4.3.3 #1 SMP Tue Jan 5 15:58:47 EST 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> # tapeinfo -f /dev/st0
> Product Type: Tape Drive
> Vendor ID: 'QUANTUM '
> Product ID: 'ULTRIUM 5       '
> Revision: '3060'
> Attached Changer API: No
> SerialNumber: 'HU1023AKHE'
> MinBlock: 1
> MaxBlock: 16777215
> SCSI ID: 0
> SCSI LUN: 0
> Ready: yes
> BufferedMode: yes
> Medium Type: Not Loaded
> Density Code: 0x58
> BlockSize: 512
> DataCompEnabled: yes
> DataCompCapable: yes
> DataDeCompEnabled: yes
> CompType: 0x1
> DeCompType: 0x1
> BOP: yes
> Block Position: 0
> Partition 0 Remaining Kbytes: 1541692
> Partition 0 Size in Kbytes: 1541692
> ActivePartition: 0
> EarlyWarningSize: 0
> NumPartitions: 0
> MaxPartitions: 0
>
> Drive is working fine,
>
> # mt -f /dev/st0 status
> SCSI 2 tape drive:
> File number=0, block number=0, partition=0.
> Tape block size 512 bytes. Density code 0x58 (no translation).
> Soft error count since last status=0
> General status bits on (41010000):
>   BOT ONLINE IM_REP_EN
>
> This is what I get when I try and partition and I believe this may be a firmware issue for me.
>
> mt -f /dev/st0  stsetoption can-partitions
>
> [ 5343.620005] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
> [ 5343.621424] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
> [ 5343.622005] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
> [ 5343.622606] st 0:0:0:0: [st0] Block size: 512, buffer size: 4096 (8 blocks).
> [ 5343.623208] st 0:0:0:0: [st0] Mode 0 options: buffer writes: 1, async writes: 1, read ahead: 1
> [ 5343.623810] st 0:0:0:0: [st0]     can bsr: 1, two FMs: 0, fast mteom: 0, auto lock: 0,
> [ 5343.624413] st 0:0:0:0: [st0]     defs for wr: 0, no block limits: 0, partitions: 1, s2 log: 0
> [ 5343.625011] st 0:0:0:0: [st0]     sysv: 0 nowait: 0 sili: 0 nowait_filemark: 0
> [ 5343.625623] st 0:0:0:0: [st0]     debugging: 1
> [ 5343.626222] st 0:0:0:0: [st0] Rewinding tape.
>
> # mt -f /dev/nst0  mkpartition 1
> /dev/nst0: Input/output error
>
>
>
>
>
> Laurence Oberman
> Principal Software Maintenance Engineer
> Red Hat Global Support Services
>
> ----- Original Message -----
> From: "Emmanuel Florac" <[e-mail]>
> To: "Laurence Oberman" <[e-mail]>
> Cc: "Laurence Oberman" <[e-mail]>, "Kai Makisara" <[e-mail]>, [e-mail]
> Sent: Wednesday, January 6, 2016 10:10:49 AM
> Subject: Re: st driver doesn't seem to grok LTO partitioning
>
> Le Tue, 5 Jan 2016 16:55:04 -0500 (EST)
> Laurence Oberman <[e-mail]> écrivait:
>
>> mt -f /dev/nst0  mkpartition 1
>>
>
> What is the type of drive exactly? I still couldn't test with the LTO-5
> drive as the machine it's connected to is being reinstalled.
>

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Laurence Oberman Jan. 6, 2016, 3:54 p.m. UTC | #11

Thanks Doug
Trying that now


Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

----- Original Message -----
From: "Douglas Gilbert" <[e-mail]>
To: "Laurence Oberman" <[e-mail]>, "Emmanuel Florac" <[e-mail]>
Cc: "Laurence Oberman" <[e-mail]>, "Kai Makisara" <[e-mail]>, [e-mail]
Sent: Wednesday, January 6, 2016 10:48:44 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning

On 16-01-06 10:32 AM, Laurence Oberman wrote:
> Firmware update fails as follows:
>
> Still researching. This is the only LTO5 I have access to so unless Shane has one I may not be able to make progress.
> (Its way long out of warranty and support)
>
> We mostly use this for generic st driver and changer testing for RHEL and it has not been updated for at least two years.
>
> Performing FUP operation...
>
> Checking image file (/root/V3210A011-E00.IMG)
>
> Checking device readiness
>
> Sending image file to the device
>
> Redetecting device
> Fup drive command failed: Unknown error! (status = -100)
>
> Host adapter status = 0x00
> Driver status = 0x08
> Error buffer = 'MSG: FupDrive() - Error committing image file to drive (/root/V3210A011-E00.IMG) 1584236 of 1584236 bytes written.
> SCSI: WriteBuffer()::DevIo() - ErrorCode (0x70h) ,Sense Key (0x05h) ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST. ASC(0x26h), ASCQ(0x00h) - )
> '
>
> Unable to perform FUP operation.

The 1584236 byte firmware image might be too big for a single
WRITE BUFFER command. You might try getting a recent version of
sg3_utils and doing something like:
    sg_write_buffer -b 4k -I V3210A011-E00.IMG -m 7 /dev/sg3

where /dev/sg3 corresponds to your tape drive. 'lsscsi -g' will
show you the mapping.

The above technique works fine for recent Seagate SAS disks (with
".LOD" firmware images).

Doug Gilbert

> ----- Original Message -----
> From: "Laurence Oberman" <[e-mail]>
> To: "Emmanuel Florac" <[e-mail]>
> Cc: "Laurence Oberman" <[e-mail]>, "Kai Makisara" <[e-mail]>, [e-mail]
> Sent: Wednesday, January 6, 2016 10:25:37 AM
> Subject: Re: st driver doesn't seem to grok LTO partitioning
>
> I left the log of the failure to partition out
>
> Here it is
>
> # mt -f /dev/nst0  mkpartition 1
> /dev/nst0: Input/output error
>
> [ 5499.341648] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
> [ 5499.342903] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
> [ 5499.343523] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
> [ 5499.344114] st 0:0:0:0: [st0] Block size: 512, buffer size: 4096 (8 blocks).
> [ 5499.344702] st 0:0:0:0: [st0] Loading tape.
> [ 5499.359733] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
> [ 5499.360970] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
> [ 5499.361584] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
> [ 5499.362165] st 0:0:0:0: [st0] Block size: 512, buffer size: 4096 (8 blocks).
> [ 5499.363851] st 0:0:0:0: [st0] Partition page length is 10 bytes.
> [ 5499.364468] st 0:0:0:0: [st0] PP: max 0, add 0, xdp 0, psum 03, pofmetc 0,rec 03, units 09, sizes: 1541 65535
> [ 5499.365074] st 0:0:0:0: [st0] MP: 11 08 00 00 18 03 09 00 06 05 ff ff
> [ 5499.365658] st 0:0:0:0: [st0] psd_cnt 2, max.parts 0, nbr_parts 0
> [ 5499.366246] st 0:0:0:0: [st0] Formatting tape with two partitions (FDP).
> [ 5499.366826] st 0:0:0:0: [st0] Sent partition page length is 12 bytes.  needs_format: 0
> [ 5499.367424] st 0:0:0:0: [st0] PP: max 0, add 1, xdp 4, psum 03, pofmetc 0 rec 03, units 00, sizes: 65535 65535
> [ 5499.368024] st 0:0:0:0: [st0] MP: 11 0a 00 01 98 03 00 00 ff ff ff ff
> [ 5499.369842] st 0:0:0:0: [st0] Error: 8000002, cmd: 15 10 0 0 18 0
> [ 5499.370495] st 0:0:0:0: [st0] Sense Key : Illegal Request [current]
> [ 5499.371109] st 0:0:0:0: [st0] Add. Sense: Invalid field in parameter list
> [ 5499.371714] st 0:0:0:0: [st0] Partitioning of tape failed.
>
> Laurence Oberman
> Principal Software Maintenance Engineer
> Red Hat Global Support Services
>
> ----- Original Message -----
> From: "Laurence Oberman" <[e-mail]>
> To: "Emmanuel Florac" <[e-mail]>
> Cc: "Laurence Oberman" <[e-mail]>, "Kai Makisara" <[e-mail]>, [e-mail]
> Sent: Wednesday, January 6, 2016 10:23:34 AM
> Subject: Re: st driver doesn't seem to grok LTO partitioning
>
> Hello Emanuel
>
> I am using this device, its an Ultrium 5 (LTO5)
> Its an older changer and I am unable to update the firmware, still working on that.
>
> What version of mt are you using, as I am testing using a RHEL7.2 base and the upstream patched kernel.
>
> Linux example.redhat.com 4.3.3 #1 SMP Tue Jan 5 15:58:47 EST 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> # tapeinfo -f /dev/st0
> Product Type: Tape Drive
> Vendor ID: 'QUANTUM '
> Product ID: 'ULTRIUM 5       '
> Revision: '3060'
> Attached Changer API: No
> SerialNumber: 'HU1023AKHE'
> MinBlock: 1
> MaxBlock: 16777215
> SCSI ID: 0
> SCSI LUN: 0
> Ready: yes
> BufferedMode: yes
> Medium Type: Not Loaded
> Density Code: 0x58
> BlockSize: 512
> DataCompEnabled: yes
> DataCompCapable: yes
> DataDeCompEnabled: yes
> CompType: 0x1
> DeCompType: 0x1
> BOP: yes
> Block Position: 0
> Partition 0 Remaining Kbytes: 1541692
> Partition 0 Size in Kbytes: 1541692
> ActivePartition: 0
> EarlyWarningSize: 0
> NumPartitions: 0
> MaxPartitions: 0
>
> Drive is working fine,
>
> # mt -f /dev/st0 status
> SCSI 2 tape drive:
> File number=0, block number=0, partition=0.
> Tape block size 512 bytes. Density code 0x58 (no translation).
> Soft error count since last status=0
> General status bits on (41010000):
>   BOT ONLINE IM_REP_EN
>
> This is what I get when I try and partition and I believe this may be a firmware issue for me.
>
> mt -f /dev/st0  stsetoption can-partitions
>
> [ 5343.620005] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
> [ 5343.621424] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
> [ 5343.622005] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
> [ 5343.622606] st 0:0:0:0: [st0] Block size: 512, buffer size: 4096 (8 blocks).
> [ 5343.623208] st 0:0:0:0: [st0] Mode 0 options: buffer writes: 1, async writes: 1, read ahead: 1
> [ 5343.623810] st 0:0:0:0: [st0]     can bsr: 1, two FMs: 0, fast mteom: 0, auto lock: 0,
> [ 5343.624413] st 0:0:0:0: [st0]     defs for wr: 0, no block limits: 0, partitions: 1, s2 log: 0
> [ 5343.625011] st 0:0:0:0: [st0]     sysv: 0 nowait: 0 sili: 0 nowait_filemark: 0
> [ 5343.625623] st 0:0:0:0: [st0]     debugging: 1
> [ 5343.626222] st 0:0:0:0: [st0] Rewinding tape.
>
> # mt -f /dev/nst0  mkpartition 1
> /dev/nst0: Input/output error
>
>
>
>
>
> Laurence Oberman
> Principal Software Maintenance Engineer
> Red Hat Global Support Services
>
> ----- Original Message -----
> From: "Emmanuel Florac" <[e-mail]>
> To: "Laurence Oberman" <[e-mail]>
> Cc: "Laurence Oberman" <[e-mail]>, "Kai Makisara" <[e-mail]>, [e-mail]
> Sent: Wednesday, January 6, 2016 10:10:49 AM
> Subject: Re: st driver doesn't seem to grok LTO partitioning
>
> Le Tue, 5 Jan 2016 16:55:04 -0500 (EST)
> Laurence Oberman <[e-mail]> écrivait:
>
>> mt -f /dev/nst0  mkpartition 1
>>
>
> What is the type of drive exactly? I still couldn't test with the LTO-5
> drive as the machine it's connected to is being reinstalled.
>

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Emmanuel Florac Jan. 6, 2016, 4:07 p.m. UTC | #12

Le Wed, 6 Jan 2016 10:23:34 -0500 (EST)
Laurence Oberman <[e-mail]> écrivait:

> MaxPartitions: 0
> 
> Drive is working fine,
> 
> # mt -f /dev/st0 status
> SCSI 2 tape drive:
> File number=0, block number=0, partition=0.
> Tape block size 512 bytes. Density code 0x58 (no translation).
> Soft error count since last status=0
> General status bits on (41010000):
>  BOT ONLINE IM_REP_EN
> 
> This is what I get when I try and partition and I believe this may be
> a firmware issue for me.

Yes probably, it reports "MaxPartitions 0", should be 1 for an LTO-5
drive. Weird.

Emmanuel Florac Jan. 6, 2016, 4:10 p.m. UTC | #13

Le Mon, 4 Jan 2016 12:46:26 +0100
Emmanuel Florac <[e-mail]> écrivait:

> That works fine for me. I'm going to do some testing with other drives
> I have (LTO-3 -- should fail -- and LTO-5).
> 

Works OK with LTO-5 (HP). Sizing the partitions is quite difficult, as
you can see. To get one "wrap" in the first partition, "1400000" and
"1424000" work, but "1450000" doesn't. Same for LTO-6 (I'm still
looking for the proper size).

# mt -f /dev/st0 mkpartition 1


Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: Updating partition number in status.
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: Got tape pos. blk 0 part 0.
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: Loading tape.
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: Partition page length is 12 bytes.
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: PP: max 1, add 0, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 1529 0
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: MP: 11 0a 01 00 3c 03 09 00 05 f9 00 00
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: psd_cnt 2, max.parts 1, nbr_parts 0
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: Formatting tape with two partitions (FDP).
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: Sent partition page length is 12 bytes. needs_format: 1
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: PP: max 1, add 1, xdp 4, psum 03, pofmetc 4, rec 03, units 00, sizes: 65535 0
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: MP: 11 0a 01 01 9c 03 00 00 ff ff 00 00
Jan  6 16:38:42 taiko kernel: st 6:0:0:0: st0: Sending FORMAT MEDIUM
Jan  6 16:38:56 taiko kernel: st 6:0:0:0: st0: Rewinding tape.


# tapeinfo -f /dev/sg1
Product Type: Tape Drive
Vendor ID: 'HP      '
Product ID: 'Ultrium 5-SCSI  '
Revision: 'Z61U'
Attached Changer API: No
SerialNumber: 'HU1249TP88'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 0
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x58
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
Partition 0 Remaining Kbytes: 1459056
Partition 0 Size in Kbytes: 1459056
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 1
MaxPartitions: 1
Partition0: 1453
Partition1: 38

# mt -f /dev/st0 setpartition 1

Jan  6 16:40:20 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  6 16:40:20 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  6 16:40:20 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1
Jan  6 16:40:20 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  6 16:40:20 taiko kernel: st 6:0:0:0: st0: Setting block to 0 and partition to 1.
Jan  6 16:40:20 taiko kernel: st 6:0:0:0: st0: Got tape pos. blk 0 part 0.
Jan  6 16:40:20 taiko kernel: st 6:0:0:0: st0: Visited block 0 for partition 0 saved.
Jan  6 16:40:20 taiko kernel: st 6:0:0:0: st0: Trying to change partition from 0 to 1
Jan  6 16:40:25 taiko kernel: st 6:0:0:0: st0: Rewinding tape.

# mt -f /dev/st0 mkpartition 1453

Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Loading tape.
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Partition page length is 12 bytes.
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: PP: max 1, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 1453 38
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: MP: 11 0a 01 01 3c 03 09 00 05 ad 00 26
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: psd_cnt 2, max.parts 1, nbr_parts 1
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Formatting tape with two partitions (1 = 1453 MB).
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Sent partition page length is 12 bytes. needs_format: 1
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: PP: max 1, add 1, xdp 1, psum 02, pofmetc 4, rec 03, units 00, sizes: 65535 1453
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: MP: 11 0a 01 01 34 03 00 00 ff ff 05 ad
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Error: 8000002, cmd: 15 10 0 0 18 0
Jan  6 16:42:22 taiko kernel: st0: Sense Key : Illegal Request [current] 
Jan  6 16:42:22 taiko kernel: st0: Add. Sense: Invalid field in parameter list
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Partitioning of tape failed.
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Rewinding tape.

# mt -f /dev/st0 setpartition 0

Jan  6 16:42:36 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  6 16:42:36 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  6 16:42:36 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1
Jan  6 16:42:36 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  6 16:42:36 taiko kernel: st 6:0:0:0: st0: Setting block to 0 and partition to 0.
Jan  6 16:42:36 taiko kernel: st 6:0:0:0: st0: Got tape pos. blk 0 part 0.
Jan  6 16:42:36 taiko kernel: st 6:0:0:0: st0: Visited block 0 for partition 1 saved.
Jan  6 16:42:36 taiko kernel: st 6:0:0:0: st0: Trying to change partition from 1 to 0
Jan  6 16:42:41 taiko kernel: st 6:0:0:0: st0: Rewinding tape.


# mt -f /dev/st0 mkpartition 1487872


Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: Loading tape.
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: Partition page length is 12 bytes.
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: PP: max 1, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 1453 38
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: MP: 11 0a 01 01 3c 03 09 00 05 ad 00 26
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: psd_cnt 2, max.parts 1, nbr_parts 1
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: Formatting tape with two partitions (1 = 1487000 MB).
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: Sent partition page length is 12 bytes. needs_format: 1
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: PP: max 1, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 65535 1487
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: MP: 11 0a 01 01 3c 03 09 00 ff ff 05 cf
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: Sending FORMAT MEDIUM
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: Error: 8000002, cmd: 4 0 1 0 0 0
Jan  6 16:44:25 taiko kernel: st0: Sense Key : Illegal Request [current] 
Jan  6 16:44:25 taiko kernel: st0: Add. Sense: Parameter value invalid
Jan  6 16:44:25 taiko kernel: st 6:0:0:0: st0: Rewinding tape.

# mt -f /dev/st0 mkpartition 77824


Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1
Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: Loading tape.
Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1
Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: Partition page length is 12 bytes.
Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: PP: max 1, add 0, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 1529 0
Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: MP: 11 0a 01 00 3c 03 09 00 05 f9 00 00
Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: psd_cnt 2, max.parts 1, nbr_parts 0
Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: Formatting tape with two partitions (1 = 77000 MB).
Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: Sent partition page length is 12 bytes. needs_format: 1
Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: PP: max 1, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 65535 77
Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: MP: 11 0a 01 01 3c 03 09 00 ff ff 00 4d
Jan  6 16:48:35 taiko kernel: st 6:0:0:0: st0: Sending FORMAT MEDIUM
Jan  6 16:48:45 taiko kernel: st 6:0:0:0: st0: Rewinding tape.

# tapeinfo -f /dev/sg1
Product Type: Tape Drive
Vendor ID: 'HP      '
Product ID: 'Ultrium 5-SCSI  '
Revision: 'Z61U'
Attached Changer API: No
SerialNumber: 'HU1249TP88'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 0
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x58
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
Partition 0 Remaining Kbytes: 1459056
Partition 0 Size in Kbytes: 1459056
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 1
MaxPartitions: 1
Partition0: 1376
Partition1: 114

# mt -f /dev/st0 mkpartition 228000


Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1
Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: Loading tape.
Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1
Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: Partition page length is 12 bytes.
Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: PP: max 1, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 1376 114
Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: MP: 11 0a 01 01 3c 03 09 00 05 60 00 72
Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: psd_cnt 2, max.parts 1, nbr_parts 1
Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: Formatting tape with two partitions (1 = 228000 MB).
Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: Sent partition page length is 12 bytes. needs_format: 1
Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: PP: max 1, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 65535 228
Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: MP: 11 0a 01 01 3c 03 09 00 ff ff 00 e4
Jan  6 16:50:26 taiko kernel: st 6:0:0:0: st0: Sending FORMAT MEDIUM
Jan  6 16:50:37 taiko kernel: st 6:0:0:0: st0: Rewinding tape.

# tapeinfo -f /dev/sg1
Product Type: Tape Drive
Vendor ID: 'HP      '
Product ID: 'Ultrium 5-SCSI  '
Revision: 'Z61U'
Attached Changer API: No
SerialNumber: 'HU1249TP88'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 0
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x58
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
Partition 0 Remaining Kbytes: 1459056
Partition 0 Size in Kbytes: 1459056
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 1
MaxPartitions: 1
Partition0: 1223
Partition1: 267

# mt -f /dev/st0 mkpartition 1400000

Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1
Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: Loading tape.
Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1
Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks).
Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: Partition page length is 12 bytes.
Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: PP: max 1, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 1223 267
Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: MP: 11 0a 01 01 3c 03 09 00 04 c7 01 0b
Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: psd_cnt 2, max.parts 1, nbr_parts 1
Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: Formatting tape with two partitions (1 = 1400000 MB).
Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: Sent partition page length is 12 bytes. needs_format: 1
Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: PP: max 1, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 65535 1400
Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: MP: 11 0a 01 01 3c 03 09 00 ff ff 05 78
Jan  6 16:52:16 taiko kernel: st 6:0:0:0: st0: Sending FORMAT MEDIUM
Jan  6 16:52:25 taiko kernel: st 6:0:0:0: st0: Rewinding tape.

# tapeinfo -f /dev/sg1
Product Type: Tape Drive
Vendor ID: 'HP      '
Product ID: 'Ultrium 5-SCSI  '
Revision: 'Z61U'
Attached Changer API: No
SerialNumber: 'HU1249TP88'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 0
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x58
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
Partition 0 Remaining Kbytes: 1459056
Partition 0 Size in Kbytes: 1459056
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 1
MaxPartitions: 1
Partition0: 38
Partition1: 1453

Emmanuel Florac Jan. 6, 2016, 4:16 p.m. UTC | #14

Le Wed, 6 Jan 2016 17:10:15 +0100
Emmanuel Florac <[e-mail]> écrivait:

> Works OK with LTO-5 (HP). Sizing the partitions is quite difficult, as
> you can see. To get one "wrap" in the first partition, "1400000" and
> "1424000" work, but "1450000" doesn't. Same for LTO-6 (I'm still
> looking for the proper size).
> 

Looks like the proper size for a "one wrap" 38 GB partition 0 on LTO-6
is "2450000". Go figure.

Emmanuel Florac Jan. 6, 2016, 4:44 p.m. UTC | #15

Le Mon, 4 Jan 2016 12:22:34 +0200 (EET)
Kai Makisara <[e-mail]> écrivait:

> The patch has been tested with my DDS-4 drive.

Oh BTW, may be you could correct this one while you're at it :) I don't
think my kernel is so old... :)

~# mt -f /dev/st0 stshowopt
Your kernel (3.18.25) may be too old for this command.
The options set: buffer-writes async-writes read-ahead debug can-bsr can-partitions

Laurence Oberman Jan. 14, 2016, 8:12 p.m. UTC | #16

All attempts to get my drive and changer firmware updated have failed.
So I wont be able to add another "tested by" to this thread unless I can find another drive.

Even using Doug's method fails to actually update. Seems to suck up the image and then do nothing.
Lands up in getting hung and needs a full power reset.

The image I have is the correct image.

I dont want to try to many convoluted methods because I dont want to brick the changer.

Its the only one I have for doing all the st driver testing here at Red Hat in the GSS team.

Thanks

Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

----- Original Message -----
From: "Emmanuel Florac" <[e-mail]>
To: "Laurence Oberman" <[e-mail]>
Cc: "Laurence Oberman" <[e-mail]>, "Kai Makisara" <[e-mail]>, [e-mail]
Sent: Wednesday, January 6, 2016 11:07:20 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning

Le Wed, 6 Jan 2016 10:23:34 -0500 (EST)
Laurence Oberman <[e-mail]> écrivait:

> MaxPartitions: 0
> 
> Drive is working fine,
> 
> # mt -f /dev/st0 status
> SCSI 2 tape drive:
> File number=0, block number=0, partition=0.
> Tape block size 512 bytes. Density code 0x58 (no translation).
> Soft error count since last status=0
> General status bits on (41010000):
>  BOT ONLINE IM_REP_EN
> 
> This is what I get when I try and partition and I believe this may be
> a firmware issue for me.

Yes probably, it reports "MaxPartitions 0", should be 1 for an LTO-5
drive. Weird.

Seymour, Shane M Jan. 15, 2016, 12:21 a.m. UTC | #17

VW5mb3J0dW5hdGVseSBJJ20gdW5hYmxlIHRvIGxheSBteSBoYW5kcyBvbiBhbiBMVE8gNSB0YXBl
IGRyaXZlIHNvIEknbSBub3QgYWJsZSB0byB0ZXN0IHRoYXQgaXQgd29ya3MgZWl0aGVyLiBJZiBp
dCBoZWxwcyBhdCBhbGwgSSBjYW4gdGVzdCBpbiB0aGUgbmVnYXRpdmUgYW5kIG1ha2Ugc3VyZSB0
aGF0IGZvciBhbiBMVE8gMyBkcml2ZSBpdCBmYWlscyBncmFjZWZ1bGx5IGJ1dCB0aGF0J3MgYWJv
dXQgaXQgYXQgdGhlIG1vbWVudC4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG
cm9tOiBsaW51eC1zY3NpLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmxpbnV4LXNjc2kt
DQo+IG93bmVyQHZnZXIua2VybmVsLm9yZ10gT24gQmVoYWxmIE9mIExhdXJlbmNlIE9iZXJtYW4N
Cj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDE1LCAyMDE2IDc6MTMgQU0NCj4gVG86IEVtbWFudWVs
IEZsb3JhYw0KPiBDYzogTGF1cmVuY2UgT2Jlcm1hbjsgS2FpIE1ha2lzYXJhOyBsaW51eC1zY3Np
QHZnZXIua2VybmVsLm9yZw0KPiBTdWJqZWN0OiBSZTogc3QgZHJpdmVyIGRvZXNuJ3Qgc2VlbSB0
byBncm9rIExUTyBwYXJ0aXRpb25pbmcNCj4gDQo+IEFsbCBhdHRlbXB0cyB0byBnZXQgbXkgZHJp
dmUgYW5kIGNoYW5nZXIgZmlybXdhcmUgdXBkYXRlZCBoYXZlIGZhaWxlZC4NCj4gU28gSSB3b250
IGJlIGFibGUgdG8gYWRkIGFub3RoZXIgInRlc3RlZCBieSIgdG8gdGhpcyB0aHJlYWQgdW5sZXNz
IEkgY2FuIGZpbmQNCj4gYW5vdGhlciBkcml2ZS4NCj4gDQo+IEV2ZW4gdXNpbmcgRG91ZydzIG1l
dGhvZCBmYWlscyB0byBhY3R1YWxseSB1cGRhdGUuIFNlZW1zIHRvIHN1Y2sgdXAgdGhlDQo+IGlt
YWdlIGFuZCB0aGVuIGRvIG5vdGhpbmcuDQo+IExhbmRzIHVwIGluIGdldHRpbmcgaHVuZyBhbmQg
bmVlZHMgYSBmdWxsIHBvd2VyIHJlc2V0Lg0KPiANCj4gVGhlIGltYWdlIEkgaGF2ZSBpcyB0aGUg
Y29ycmVjdCBpbWFnZS4NCj4gDQo+IEkgZG9udCB3YW50IHRvIHRyeSB0byBtYW55IGNvbnZvbHV0
ZWQgbWV0aG9kcyBiZWNhdXNlIEkgZG9udCB3YW50IHRvIGJyaWNrDQo+IHRoZSBjaGFuZ2VyLg0K
PiANCj4gSXRzIHRoZSBvbmx5IG9uZSBJIGhhdmUgZm9yIGRvaW5nIGFsbCB0aGUgc3QgZHJpdmVy
IHRlc3RpbmcgaGVyZSBhdCBSZWQgSGF0IGluIHRoZQ0KPiBHU1MgdGVhbS4NCj4gDQo+IFRoYW5r
cw0KPiANCj4gTGF1cmVuY2UgT2Jlcm1hbg0KPiBQcmluY2lwYWwgU29mdHdhcmUgTWFpbnRlbmFu
Y2UgRW5naW5lZXINCj4gUmVkIEhhdCBHbG9iYWwgU3VwcG9ydCBTZXJ2aWNlcw0KPiANCj4gLS0t
LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiAiRW1tYW51ZWwgRmxvcmFjIiA8ZWZs
b3JhY0BpbnRlbGxpcXVlLmNvbT4NCj4gVG86ICJMYXVyZW5jZSBPYmVybWFuIiA8bG9iZXJtYW5A
cmVkaGF0LmNvbT4NCj4gQ2M6ICJMYXVyZW5jZSBPYmVybWFuIiA8b2Jlcm1hbi5sQGdtYWlsLmNv
bT4sICJLYWkgTWFraXNhcmEiDQo+IDxLYWkuTWFraXNhcmFAa29sdW1idXMuZmk+LCBsaW51eC1z
Y3NpQHZnZXIua2VybmVsLm9yZw0KPiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgNiwgMjAxNiAx
MTowNzoyMCBBTQ0KPiBTdWJqZWN0OiBSZTogc3QgZHJpdmVyIGRvZXNuJ3Qgc2VlbSB0byBncm9r
IExUTyBwYXJ0aXRpb25pbmcNCj4gDQo+IExlIFdlZCwgNiBKYW4gMjAxNiAxMDoyMzozNCAtMDUw
MCAoRVNUKQ0KPiBMYXVyZW5jZSBPYmVybWFuIDxsb2Jlcm1hbkByZWRoYXQuY29tPiDDqWNyaXZh
aXQ6DQo+IA0KPiA+IE1heFBhcnRpdGlvbnM6IDANCj4gPg0KPiA+IERyaXZlIGlzIHdvcmtpbmcg
ZmluZSwNCj4gPg0KPiA+ICMgbXQgLWYgL2Rldi9zdDAgc3RhdHVzDQo+ID4gU0NTSSAyIHRhcGUg
ZHJpdmU6DQo+ID4gRmlsZSBudW1iZXI9MCwgYmxvY2sgbnVtYmVyPTAsIHBhcnRpdGlvbj0wLg0K
PiA+IFRhcGUgYmxvY2sgc2l6ZSA1MTIgYnl0ZXMuIERlbnNpdHkgY29kZSAweDU4IChubyB0cmFu
c2xhdGlvbikuDQo+ID4gU29mdCBlcnJvciBjb3VudCBzaW5jZSBsYXN0IHN0YXR1cz0wDQo+ID4g
R2VuZXJhbCBzdGF0dXMgYml0cyBvbiAoNDEwMTAwMDApOg0KPiA+ICBCT1QgT05MSU5FIElNX1JF
UF9FTg0KPiA+DQo+ID4gVGhpcyBpcyB3aGF0IEkgZ2V0IHdoZW4gSSB0cnkgYW5kIHBhcnRpdGlv
biBhbmQgSSBiZWxpZXZlIHRoaXMgbWF5IGJlDQo+ID4gYSBmaXJtd2FyZSBpc3N1ZSBmb3IgbWUu
DQo+IA0KPiBZZXMgcHJvYmFibHksIGl0IHJlcG9ydHMgIk1heFBhcnRpdGlvbnMgMCIsIHNob3Vs
ZCBiZSAxIGZvciBhbiBMVE8tNSBkcml2ZS4NCj4gV2VpcmQuDQo+IA0KPiAtLQ0KPiAtLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NCj4gRW1tYW51ZWwgRmxvcmFjICAgICB8ICAgRGlyZWN0aW9uIHRlY2huaXF1ZQ0K
PiAgICAgICAgICAgICAgICAgICAgIHwgICBJbnRlbGxpcXVlDQo+ICAgICAgICAgICAgICAgICAg
ICAgfAk8ZWZsb3JhY0BpbnRlbGxpcXVlLmNvbT4NCj4gICAgICAgICAgICAgICAgICAgICB8ICAg
KzMzIDEgNzggOTQgODQgMDINCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+IFRvIHVuc3Vic2Ny
aWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsaW51eC1zY3Np
IiBpbiB0aGUNCj4gYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9y
ZyBNb3JlIG1ham9yZG9tbyBpbmZvIGF0DQo+IGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jk
b21vLWluZm8uaHRtbA0K
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Emmanuel Florac Jan. 15, 2016, 11:48 a.m. UTC | #18

Le Thu, 14 Jan 2016 15:12:53 -0500 (EST)
Laurence Oberman <[e-mail]> écrivait:

> All attempts to get my drive and changer firmware updated have failed.
> So I wont be able to add another "tested by" to this thread unless I
> can find another drive.

Too bad, would have been good to test on a different brand. I have an
IBM drive somewhere, but it's an LTO-4 alas. I know that IBM and HP
drives may have some significant differences in behaviour.

Kai Mäkisara (Kolumbus) Jan. 21, 2016, 8:58 p.m. UTC | #19

> On 15.1.2016, at 2.21, Seymour, Shane M <[e-mail]> wrote:
> 
> Unfortunately I'm unable to lay my hands on an LTO 5 tape drive so I'm not able to test that it works either. If it helps at all I can test in the negative and make sure that for an LTO 3 drive it fails gracefully but that's about it at the moment.

Thanks for all testers and those who attempted to test. The latest patch applies the standard quite strictly and I think it should work with most drives. The implementation can be fixed later if problems are found.

However, before making the final patch, we should decide which partition the specified size should apply to. For the SCSI level <=2 it applies to partition 1. For other drives we may have some freedom to “tune” the definition. The size should apply to the partition the users expect it to apply. 

The current documentation says "the argument gives in megabytes the size of partition 1 that is physically the first partition of the tape”. The documentation I have found for current drives (HP and IBM LTO, IBM 3592, Storagetek T1000) all number the partitions sequentially from the start of the tape. The access time for any partition is probably about the same when wrapwise partitioning is used. It does matter with linear partitioning. Unfortunately, the standards leave the numbering to the implementor.

Partitioning with two partitions is used for storing index in a small partition and use the rest of the tape for data. In this case, it is probably natural to specify the size of the index. The LTFS definition supports index in any partition. The open source code I have seen seem to default to index in partition 0.

The HP and IBM LTO default partitioning (FDP=1) specifies two wraps (minimum) to partition 1 and the rest to 0.

There seem to be lot of arguments supporting both possible choices. Should we use the existing definition (1) or change it for the drives supporting SCSI level >= 3 (or supporting FORMAT MEDIUM)? The definition can’t be changed later. This is why we should make a good decision.

Opinions?

Thanks,
Kai

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Laurence Oberman Jan. 21, 2016, 10:06 p.m. UTC | #20

Given what we see at customers I am leaning towards the SCSI level <=2 to ensure the older LTO5's are supported.
The newer ones should be backwards compatible.
I may have an older LTO5 showing up that wont need a F/W update to work, and will be able to add a "tested by" once I get it.

But lets see what the others have to say

Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

----- Original Message -----
From: "Kai Mäkisara (Kolumbus)" <[e-mail]>
To: "Shane M Seymour" <[e-mail]>
Cc: "Laurence Oberman" <[e-mail]>, "Emmanuel Florac" <[e-mail]>, "Laurence Oberman" <[e-mail]>, [e-mail]
Sent: Thursday, January 21, 2016 3:58:46 PM
Subject: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning


> On 15.1.2016, at 2.21, Seymour, Shane M <[e-mail]> wrote:
> 
> Unfortunately I'm unable to lay my hands on an LTO 5 tape drive so I'm not able to test that it works either. If it helps at all I can test in the negative and make sure that for an LTO 3 drive it fails gracefully but that's about it at the moment.

Thanks for all testers and those who attempted to test. The latest patch applies the standard quite strictly and I think it should work with most drives. The implementation can be fixed later if problems are found.

However, before making the final patch, we should decide which partition the specified size should apply to. For the SCSI level <=2 it applies to partition 1. For other drives we may have some freedom to “tune” the definition. The size should apply to the partition the users expect it to apply. 

The current documentation says "the argument gives in megabytes the size of partition 1 that is physically the first partition of the tape”. The documentation I have found for current drives (HP and IBM LTO, IBM 3592, Storagetek T1000) all number the partitions sequentially from the start of the tape. The access time for any partition is probably about the same when wrapwise partitioning is used. It does matter with linear partitioning. Unfortunately, the standards leave the numbering to the implementor.

Partitioning with two partitions is used for storing index in a small partition and use the rest of the tape for data. In this case, it is probably natural to specify the size of the index. The LTFS definition supports index in any partition. The open source code I have seen seem to default to index in partition 0.

The HP and IBM LTO default partitioning (FDP=1) specifies two wraps (minimum) to partition 1 and the rest to 0.

There seem to be lot of arguments supporting both possible choices. Should we use the existing definition (1) or change it for the drives supporting SCSI level >= 3 (or supporting FORMAT MEDIUM)? The definition can’t be changed later. This is why we should make a good decision.

Opinions?

Thanks,
Kai

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Seymour, Shane M Jan. 22, 2016, 2:10 a.m. UTC | #21

Hi Kai,

> -----Original Message-----

> From: [e-mail] [mailto:linux-scsi-

> [e-mail]] On Behalf Of "Kai Mäkisara (Kolumbus)"

> Sent: Friday, January 22, 2016 7:59 AM

> To: Seymour, Shane M

> Cc: Laurence Oberman; Emmanuel Florac; Laurence Oberman; linux-

> [e-mail]

> Subject: What partition should the MTMKPART argument specify? Was: Re:

> st driver doesn't seem to grok LTO partitioning

> 

> 

> > On 15.1.2016, at 2.21, Seymour, Shane M <[e-mail]>

> wrote:

> >

> > Unfortunately I'm unable to lay my hands on an LTO 5 tape drive so I'm not

> able to test that it works either. If it helps at all I can test in the negative and

> make sure that for an LTO 3 drive it fails gracefully but that's about it at the

> moment.

> 

> Thanks for all testers and those who attempted to test. The latest patch

> applies the standard quite strictly and I think it should work with most drives.

> The implementation can be fixed later if problems are found.

> 

> However, before making the final patch, we should decide which partition

> the specified size should apply to. For the SCSI level <=2 it applies to partition

> 1. For other drives we may have some freedom to “tune” the definition. The

> size should apply to the partition the users expect it to apply.


I'd argue for consistency here in the current interface and that it should 
apply in the same way more on that below.

> 

> The current documentation says "the argument gives in megabytes the size

> of partition 1 that is physically the first partition of the tape”. The

> documentation I have found for current drives (HP and IBM LTO, IBM 3592,

> Storagetek T1000) all number the partitions sequentially from the start of the

> tape. The access time for any partition is probably about the same when

> wrapwise partitioning is used. It does matter with linear partitioning.

> Unfortunately, the standards leave the numbering to the implementor.

> 

> Partitioning with two partitions is used for storing index in a small partition

> and use the rest of the tape for data. In this case, it is probably natural to

> specify the size of the index. The LTFS definition supports index in any

> partition. The open source code I have seen seem to default to index in

> partition 0.

> 

> The HP and IBM LTO default partitioning (FDP=1) specifies two wraps

> (minimum) to partition 1 and the rest to 0.


It may be worth noting (if you're going to update any documentation)
that isn't 100% accurate. You actually get one wrap in partition 1 and the
rest minus one wrap into partition 0. There is one wrap used as a guard
between the two partitions. The size given to a partition is rounded up
to the size of a wrap as well.

See https://docs.oracle.com/cd/E21419_04/en/LTO5_Vol3_E5b/LTO5_Vol3_E5b.pdf

Page 100 where it gives examples of how partition sizes are calculated on HP LTO5 drives.

> 

> There seem to be lot of arguments supporting both possible choices. Should

> we use the existing definition (1) or change it for the drives supporting SCSI

> level >= 3 (or supporting FORMAT MEDIUM)? The definition can’t be

> changed later. This is why we should make a good decision.

> 

> Opinions?


How about using the fact the size is signed to indicate one slightly different
thing? I'm not sure if you'd call this using or abusing the fact that it's signed.

Make the default behavior for a positive size the same as the current
behavior for SCSI-2 (size applies to partition 1). If the size is negative then
the absolute value of the size applies to partition 0. That provides some
flexibility in choosing which partition the size applies to if it worked that
way for all devices.

With that you also get consistent behavior between tape drives without
having to know if the size will apply to partition 0 or partition 1 based on
the tape technology and you get the benefit of being able to set an
explicit size for partition 0 or partition 1.

You could overload the value of 0 as well to use FDP to choose the sizes
for the partitions (assuming 0 doesn't already have a side effect in
the code). Then you get whatever the tape drive wants to do.

Thanks
Shane

> 

> Thanks,

> Kai

> 

> --

> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the

> body of a message to [e-mail] More majordomo info at

> http://vger.kernel.org/majordomo-info.html

Seymour, Shane M Jan. 22, 2016, 3:31 a.m. UTC | #22

TXkgYXBwbG9naWVzOg0KDQo+IEl0IG1heSBiZSB3b3J0aCBub3RpbmcgKGlmIHlvdSdyZSBnb2lu
ZyB0byB1cGRhdGUgYW55IGRvY3VtZW50YXRpb24pIHRoYXQNCj4gaXNuJ3QgMTAwJSBhY2N1cmF0
ZS4gWW91IGFjdHVhbGx5IGdldCBvbmUgd3JhcCBpbiBwYXJ0aXRpb24gMSBhbmQgdGhlIHJlc3QN
Cj4gbWludXMgb25lIHdyYXAgaW50byBwYXJ0aXRpb24gMC4gVGhlcmUgaXMgb25lIHdyYXAgdXNl
ZCBhcyBhIGd1YXJkIGJldHdlZW4NCj4gdGhlIHR3byBwYXJ0aXRpb25zLiBUaGUgc2l6ZSBnaXZl
biB0byBhIHBhcnRpdGlvbiBpcyByb3VuZGVkIHVwIHRvIHRoZSBzaXplIG9mIGENCj4gd3JhcCBh
cyB3ZWxsLg0KPiANCj4gU2VlDQo+IGh0dHBzOi8vZG9jcy5vcmFjbGUuY29tL2NkL0UyMTQxOV8w
NC9lbi9MVE81X1ZvbDNfRTViL0xUTzVfVm9sM19FNWIuDQo+IHBkZg0KPiANCj4gUGFnZSAxMDAg
d2hlcmUgaXQgZ2l2ZXMgZXhhbXBsZXMgb2YgaG93IHBhcnRpdGlvbiBzaXplcyBhcmUgY2FsY3Vs
YXRlZCBvbiBIUA0KPiBMVE81IGRyaXZlcy4NCg0KSSBzaG91bGQgaGF2ZSBhY3R1YWxseSBzYWlk
Og0KDQpZb3UgZG8gZ2V0IHR3byB3cmFwcyBhcyBhIG1pbmltdW0gaW4gcGFydGl0aW9uIDEgYW5k
IHRoZSByZXN0IG1pbnVzIHR3byB3cmFwcw0KaW50byBwYXJ0aXRpb24gMC4gVGhlIGV4dHJhIHR3
byB3cmFwcyBhcmUgdXNlZCBhcyBhIGd1YXJkIGJldHdlZW4gdGhlIHR3byBwYXJ0aXRpb25zDQph
bmQgYWxsIHNpemVzIHdpbGwgYmUgcm91bmRlZCB0byBhIG11bHRpcGxlIG9mIHR3byB3cmFwcy4N
Cg0KVGhhdCB3YXMganVzdCB0byBtYWtlIGl0IGNsZWFyIHRoYXQgcGFydGl0aW9uIHNpemVzIHdp
bGwgYWx3YXlzIGVuZCB1cCBiZWluZyBhIG11bHRpcGxlDQpvZiAyeCB0aGUgd3JhcCBzaXplIGFu
ZCB0aGF0IHRoZXJlIHdhcyBzb21lIGZpeGVkIG92ZXJoZWFkIGluIHBhcnRpdGlvbmluZyBhbg0K
TFRPNSsgZHJpdmUgKDIgd3JhcHMpLg0K
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Douglas Gilbert Jan. 22, 2016, 10:17 a.m. UTC | #23

Laurence,
Shane Seymour from HP provided this useful link:
   https://docs.oracle.com/cd/E21419_04/en/LTO5_Vol3_E5b/LTO5_Vol3_E5b.pdf

That documents the WRITE BUFFER command on pages 228 and 229 used
by HP LTO-5 drives. For sending new firmware it looks like you need
to use MODE 4 or 5. [That description does not look like the work of
an engineer who understands the subject matter :-)].

And it seems like HP implement the REPORT SUPPORTED OPCODES command
which means you can use the sg_opcodes utility. For the WRITE BUFFER
command, that should break out the MODE numbers that the drive
actually supports. For example, this from a SSD:
...
  3b  0  10  Write buffer, combined header and data [or multiple modes]
  3b  2  10  Write buffer, data
  3b  4  10  Write buffer, download microcode and activate
  3b  5  10  Write buffer, download microcode, save, and activate
  3b  6  10  Write buffer, download microcode with offsets and activate
  3b  7  10  Write buffer, download microcode with offsets, save, and activate
  3b  a  10  Write buffer, write data to echo buffer
...

Looking back in this thread I see you mention a Quantum Ultrium 5
tape drive; so this HP information may not apply.

Doug Gilbert


On 16-01-14 09:12 PM, Laurence Oberman wrote:
> All attempts to get my drive and changer firmware updated have failed.
> So I wont be able to add another "tested by" to this thread unless I can find another drive.
>
> Even using Doug's method fails to actually update. Seems to suck up the image and then do nothing.
> Lands up in getting hung and needs a full power reset.
>
> The image I have is the correct image.
>
> I dont want to try to many convoluted methods because I dont want to brick the changer.
>
> Its the only one I have for doing all the st driver testing here at Red Hat in the GSS team.
>
> Thanks
>
> Laurence Oberman
> Principal Software Maintenance Engineer
> Red Hat Global Support Services
>
> ----- Original Message -----
> From: "Emmanuel Florac" <[e-mail]>
> To: "Laurence Oberman" <[e-mail]>
> Cc: "Laurence Oberman" <[e-mail]>, "Kai Makisara" <[e-mail]>, [e-mail]
> Sent: Wednesday, January 6, 2016 11:07:20 AM
> Subject: Re: st driver doesn't seem to grok LTO partitioning
>
> Le Wed, 6 Jan 2016 10:23:34 -0500 (EST)
> Laurence Oberman <[e-mail]> écrivait:
>
>> MaxPartitions: 0
>>
>> Drive is working fine,
>>
>> # mt -f /dev/st0 status
>> SCSI 2 tape drive:
>> File number=0, block number=0, partition=0.
>> Tape block size 512 bytes. Density code 0x58 (no translation).
>> Soft error count since last status=0
>> General status bits on (41010000):
>>   BOT ONLINE IM_REP_EN
>>
>> This is what I get when I try and partition and I believe this may be
>> a firmware issue for me.
>
> Yes probably, it reports "MaxPartitions 0", should be 1 for an LTO-5
> drive. Weird.
>

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Emmanuel Florac Jan. 22, 2016, 11:24 a.m. UTC | #24

Le Fri, 22 Jan 2016 02:10:03 +0000
"Seymour, Shane M" <[e-mail]> écrivait:

> > However, before making the final patch, we should decide which
> > partition the specified size should apply to. For the SCSI level
> > <=2 it applies to partition 1. For other drives we may have some
> > freedom to “tune” the definition. The size should apply to the
> > partition the users expect it to apply.  
> 
> I'd argue for consistency here in the current interface and that it
> should apply in the same way more on that below.

I agree, it would be extremely surprising (in a bad way) to see your
application behave differently when upgrading your drive, for instance.

> > Partitioning with two partitions is used for storing index in a
> > small partition and use the rest of the tape for data. In this
> > case, it is probably natural to specify the size of the index. The
> > LTFS definition supports index in any partition. The open source
> > code I have seen seem to default to index in partition 0.
> > 
> > The HP and IBM LTO default partitioning (FDP=1) specifies two wraps
> > (minimum) to partition 1 and the rest to 0.  

LTFS 2.2 specifications doesn't explicitly number partitions, however
it makes it clear that the "index" partition (the smaller one) must come
first. Furthermore, all LTFS tapes I've had a look at have partition 0
as index. 
Add to this the fact that current LTO-7 tapes are 6 TB. That comes to
pretty big numbers when you want to size a partition in MB. 

> It may be worth noting (if you're going to update any documentation)
> that isn't 100% accurate. You actually get one wrap in partition 1
> and the rest minus one wrap into partition 0. There is one wrap used
> as a guard between the two partitions. The size given to a partition
> is rounded up to the size of a wrap as well.
> 
> See
> https://docs.oracle.com/cd/E21419_04/en/LTO5_Vol3_E5b/LTO5_Vol3_E5b.pdf
> 
> Page 100 where it gives examples of how partition sizes are
> calculated on HP LTO5 drives.
> 

Ican confirm this from the tests I've made on LTO-5 and LTO-6. The size
of the partition you'll obtain may end quite different from the size
you've asked for. This is made particularly difficult when you must
convert a few TB to MB, and you don't know exactly where it'll 

> > 
> > There seem to be lot of arguments supporting both possible choices.
> > Should we use the existing definition (1) or change it for the
> > drives supporting SCSI level >= 3 (or supporting FORMAT MEDIUM)?
> > The definition can’t be changed later. This is why we should make a
> > good decision.
> > 
> > Opinions?  
> 
> How about using the fact the size is signed to indicate one slightly
> different thing? I'm not sure if you'd call this using or abusing the
> fact that it's signed.
> 
> Make the default behavior for a positive size the same as the current
> behavior for SCSI-2 (size applies to partition 1). If the size is
> negative then the absolute value of the size applies to partition 0.
> That provides some flexibility in choosing which partition the size
> applies to if it worked that way for all devices.
> 
> With that you also get consistent behavior between tape drives without
> having to know if the size will apply to partition 0 or partition 1
> based on the tape technology and you get the benefit of being able to
> set an explicit size for partition 0 or partition 1.
> 
> You could overload the value of 0 as well to use FDP to choose the
> sizes for the partitions (assuming 0 doesn't already have a side
> effect in the code). Then you get whatever the tape drive wants to do.

Emmanuel Florac Jan. 22, 2016, 11:50 a.m. UTC | #25

Ooops, fat finger posting before I've finished answering...

Le Fri, 22 Jan 2016 02:10:03 +0000
"Seymour, Shane M" <[e-mail]> écrivait:

> > 
> > There seem to be lot of arguments supporting both possible choices.
> > Should we use the existing definition (1) or change it for the
> > drives supporting SCSI level >= 3 (or supporting FORMAT MEDIUM)?
> > The definition can’t be changed later. This is why we should make a
> > good decision.
> > 
> > Opinions?  
>
> How about using the fact the size is signed to indicate one slightly
> different thing? I'm not sure if you'd call this using or abusing the
> fact that it's signed.
> 

I find the idea of using negative number as "interesting". I'm afraid
of what will happen as tape size grows? Don't we risk overflowing at
some point, and ending with very unexpected results?

Hmm in fact if we keep using MB we'll be stuck when tapes reach ~2 PB
which leaves some time to think about it, until LTO-15 circa 2036 :)

I have a different proposition: what about adding a new ioctl named
MTMKADVPART that takes a struct to define many different partitions at
once? So that we'd be able to create 2 partitions with the existing
MTMKPART, and also create several partitions for newer drives?

Added bonus a corresponding ioctl to read the media configuration as
specified in mode sense page 11h (see LTO SCSI reference) and present
it back so that we could know how the tape is actually partitioned :)

Seymour, Shane M Jan. 26, 2016, 11:35 p.m. UTC | #26

Hi Emmanuel,

> Hmm in fact if we keep using MB we'll be stuck when tapes reach ~2 PB

> which leaves some time to think about it, until LTO-15 circa 2036 :)


There will be other issues to solve before then (by LTO-9 2 with compression
or LTO-10 without compression and we're at LTO-7 now). Take tar format
archives with a standard block size of 10k can take this much data to get
 to 2^32 blocks and cause the current 32bit block number to wrap:

43,980,465,111,040 (2^32 * 10240)

After that much data has been written the SCSI-2 command READ POSITION
will not be able to show the current position correctly (which is what the st
driver uses to determine the position for an MTIOCPOS). It may be less
than that since some drives include file marks in the logical block number if
the program that produced the tape writes them out.

That means switching to the extended block id form of READ POSITION
so we have 64bit counts for those values, see page 150:

https://docs.oracle.com/cd/E21419_04/en/LTO5_Vol3_E5b/LTO5_Vol3_E5b.pdf

That's going to require new ioctls like MTIOCPOS64 and other changes within
the driver to support larger types for holding some values. That will also raise
all sorts of fun compatibility questions as well (should MTIOCPOS work at all
for such a tape drive or should it work until something overflows and return
what data it can and give an errno of -EOVERFLOW etc).

That's probably the correct time to also look at adding support for more
partitions. Not sure when the extended block id form of READ POSITION
got added but it may mean only supporting the wider values only with tape
drives that support REPORT SUPPORTED OPCODES (if that can indicate that
it supports READ POSITION with extended block ids and anything else
required to support block numbers larger than 2^32).

The 0x91 version of SPACE needs to be used as well (the 32bit version 0x11
Is currently used) to allow tape movement with counts >2^32. That requires
a new ioctl call. I haven't looked at what else may need to change but there's
likely to be more. The alternate version of SPACE is from page 220 of the
above HP LTO5 tape reference.

Thanks
Shane

P.S. you could force the above changes now using a 512 byte block size since
the block number would wrap at this size on LTO (ignoring the fact that it
wouldn't make sense to use a block size that small on LTO):

2,199,023,255,552 (2^32*512)

Kai Mäkisara (Kolumbus) Jan. 28, 2016, 5:31 p.m. UTC | #27

> On 27.1.2016, at 1.35, Seymour, Shane M <[e-mail]> wrote:
> 
> Hi Emmanuel,
> 
>> Hmm in fact if we keep using MB we'll be stuck when tapes reach ~2 PB
>> which leaves some time to think about it, until LTO-15 circa 2036 :)
> 
> There will be other issues to solve before then (by LTO-9 2 with compression
> or LTO-10 without compression and we're at LTO-7 now). Take tar format
> archives with a standard block size of 10k can take this much data to get
> to 2^32 blocks and cause the current 32bit block number to wrap:
> 
> 43,980,465,111,040 (2^32 * 10240)
> 
This is a somewhat theoretic example. In the 1990s no reasonable person used
block size below 32 kB. Now the limit is probably higher. But, eventually we have
to enlarge the block position and count variables.

> After that much data has been written the SCSI-2 command READ POSITION
> will not be able to show the current position correctly (which is what the st
> driver uses to determine the position for an MTIOCPOS). It may be less
> than that since some drives include file marks in the logical block number if
> the program that produced the tape writes them out.
> 
> That means switching to the extended block id form of READ POSITION
> so we have 64bit counts for those values, see page 150:
> 
> https://docs.oracle.com/cd/E21419_04/en/LTO5_Vol3_E5b/LTO5_Vol3_E5b.pdf
> 
> That's going to require new ioctls like MTIOCPOS64 and other changes within
> the driver to support larger types for holding some values. That will also raise
> all sorts of fun compatibility questions as well (should MTIOCPOS work at all
> for such a tape drive or should it work until something overflows and return
> what data it can and give an errno of -EOVERFLOW etc).
> 
I think we should support MTIOCPOS as far as we can. There is no point to
make existing software unusable for people who happen to buy a modern
drive. Note also that the block number given to MTIOCPOS is long, i.e.,
64 bits in the important architectures ;-) (The argument to MTSEEK is
int, though.)

> That's probably the correct time to also look at adding support for more
> partitions. Not sure when the extended block id form of READ POSITION
> got added but it may mean only supporting the wider values only with tape
> drives that support REPORT SUPPORTED OPCODES (if that can indicate that
> it supports READ POSITION with extended block ids and anything else
> required to support block numbers larger than 2^32).
> 
The current driver supports using up to ST_NBR_PARTITIONS (in the source set
to 4). Support for using partitions must be in the driver. I am still not sure if
partitioning the tape should be in the driver.

> The 0x91 version of SPACE needs to be used as well (the 32bit version 0x11
> Is currently used) to allow tape movement with counts >2^32. That requires
> a new ioctl call. I haven't looked at what else may need to change but there's
> likely to be more. The alternate version of SPACE is from page 220 of the
> above HP LTO5 tape reference.
> 
The first step is to make the internal counters 64 bits. Then the code should be
changed so that it can handle the large addresses. Note that this is necessary
for handling partition changes even if no positioning commands are exposed
to the user. The last step is to introduce the new positioning methods.

The new positioning methods should perhaps be defined so that both the partition
number and the block number are specified together. A proper tape address needs
both.

But I think we should first fix the existing partitioning command so that it works
for current drives.

Kai

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Emmanuel Florac Jan. 28, 2016, 5:39 p.m. UTC | #28

Le Thu, 28 Jan 2016 19:31:10 +0200
"Kai Mäkisara (Kolumbus)" <[e-mail]> écrivait:

> > On 27.1.2016, at 1.35, Seymour, Shane M <[e-mail]>
> > wrote:
> > 
> > Hi Emmanuel,
> >   
> >> Hmm in fact if we keep using MB we'll be stuck when tapes reach ~2
> >> PB which leaves some time to think about it, until LTO-15 circa
> >> 2036 :)  
> > 
> > There will be other issues to solve before then (by LTO-9 2 with
> > compression or LTO-10 without compression and we're at LTO-7 now).
> > Take tar format archives with a standard block size of 10k can take
> > this much data to get to 2^32 blocks and cause the current 32bit
> > block number to wrap:
> > 
> > 43,980,465,111,040 (2^32 * 10240)
> >   
> This is a somewhat theoretic example. In the 1990s no reasonable
> person used block size below 32 kB. Now the limit is probably higher.
> But, eventually we have to enlarge the block position and count
> variables.

You'd be surprised. In fact current LTO drive performance maxes out
between 32k and 256k. Most people would use 64k. Default for LTFS is
512k. Many, many people just use tar with the default block size, not
knowing any better (yay, shoeshine).
 
> > That's probably the correct time to also look at adding support for
> > more partitions. Not sure when the extended block id form of READ
> > POSITION got added but it may mean only supporting the wider values
> > only with tape drives that support REPORT SUPPORTED OPCODES (if
> > that can indicate that it supports READ POSITION with extended
> > block ids and anything else required to support block numbers
> > larger than 2^32). 

> The current driver supports using up to ST_NBR_PARTITIONS (in the
> source set to 4). Support for using partitions must be in the driver.
> I am still not sure if partitioning the tape should be in the driver.

As a "normal" user, I pretty much don't want to ever have to look at
these atrocious SCSI reference docs :) So I'm all for as many things as
possible to be exposed through the driver instead. I'm pretty confident
that I'm expressing the ordinary developer/admin point of view here :)


> > The 0x91 version of SPACE needs to be used as well (the 32bit
> > version 0x11 Is currently used) to allow tape movement with counts
> > >2^32. That requires a new ioctl call. I haven't looked at what
> > >else may need to change but there's
> > likely to be more. The alternate version of SPACE is from page 220
> > of the above HP LTO5 tape reference.
> >   
> The first step is to make the internal counters 64 bits. Then the
> code should be changed so that it can handle the large addresses.
> Note that this is necessary for handling partition changes even if no
> positioning commands are exposed to the user. The last step is to
> introduce the new positioning methods.
> 
> The new positioning methods should perhaps be defined so that both
> the partition number and the block number are specified together. A
> proper tape address needs both.
> 

Sounds good.

> But I think we should first fix the existing partitioning command so
> that it works for current drives.

Definitely :)

Emmanuel Florac July 18, 2018, 3:58 p.m. UTC | #29

Le Fri, 15 Jan 2016 12:48:09 +0100
Emmanuel Florac <[e-mail]> écrivait:

> Le Thu, 14 Jan 2016 15:12:53 -0500 (EST)
> Laurence Oberman <[e-mail]> écrivait:
> 
> > All attempts to get my drive and changer firmware updated have
> > failed. So I wont be able to add another "tested by" to this thread
> > unless I can find another drive.  
> 
> Too bad, would have been good to test on a different brand. I have an
> IBM drive somewhere, but it's an LTO-4 alas. I know that IBM and HP
> drives may have some significant differences in behaviour.

I finally tested with an IBM LTO-6 drive, and as feared, it
doesn't behave like the HP LTO-6 drive.

I had previously found that partitioning an LTO-6 tape using an HP drive
like this worked just fine:

mt -f /dev/nst0 mkpartition 2450000

It actually silently rounds the value to the closest number. However,
the very same command fails with an IBM drive with an "input output
error", and the following output in dmesg ( st driver in debug mode):


[8329294.626574] st 7:0:2:0: [st0] Loading tape.
[8329294.631672] st 7:0:2:0: [st0] Block limits 1 - 8388608 bytes.
[8329294.632350] st 7:0:2:0: [st0] Mode sense. Length 11, medium 68, WBS 10, BLL 8
[8329294.632352] st 7:0:2:0: [st0] Density 5a, tape length: 0, drv buffer: 1
[8329294.632354] st 7:0:2:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
[8329294.633210] st 7:0:2:0: [st0] Partition page length is 16 bytes.
[8329294.633213] st 7:0:2:0: [st0] psd_cnt 2, max.parts 3, nbr_parts 0
[8329294.633214] st 7:0:2:0: [st0] Formatting tape with two partitions (1 = 2450000 MB).
[8329294.635533] st 7:0:2:0: [st0] Error: 8000002, cmd: 15 10 0 0 18 0
[8329294.635536] st 7:0:2:0: [st0] Sense Key : Illegal Request [current] 
[8329294.635539] st 7:0:2:0: [st0] Add. Sense: Invalid field in parameter list
[8329294.635541] st 7:0:2:0: [st0] Partitioning of tape failed.

However with a slightly lower size it works:

root@srv-num-4:~# mt -f /dev/nst0 mkpartition 2426400

With the log output:

Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Block limits 1 - 8388608 bytes.
Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Mode sense. Length 11, medium 68, WBS 10, BLL 8
Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Density 5a, tape length: 0, drv buffer: 1
Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Loading tape.
Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Block limits 1 - 8388608 bytes.
Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Mode sense. Length 11, medium 68, WBS 10, BLL 8
Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Density 5a, tape length: 0, drv buffer: 1
Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Partition page length is 16 bytes.
Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] psd_cnt 2, max.parts 3, nbr_parts 0
Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Formatting tape with two partitions (1 = 2426000 MB).
Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Error: 8000002, cmd: 15 10 0 0 18 0
Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Sense Key : Recovered Error [current]
Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Add. Sense: Rounded parameter
Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Recovered ioctl error (1).
Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Sending FORMAT MEDIUM

Contrary to the HP drive, the IBM drive let us know that the parameter
we passed was slightly off and rounded to the nearest value, which is
the polite thing to do. Unfortunately, another difference with the HP
drive is that it only rounds to the *highest* nearest value, and
doesn't bother rounding down, so a slightly too high value will go
unnoticed with the HP drive, and will fail completely with the IBM one.

Isn't life wonderful?

Cheers,

Patch

--- ref/drivers/scsi/st.c	2015-12-21 18:54:05.068882001 +0200
+++ new/drivers/scsi/st.c	2016-01-04 12:09:07.702559815 +0200
@@ -9,7 +9,7 @@ 
    Steve Hirsch, Andreas Koppenh"ofer, Michael Leodolter, Eyal Lebedinsky,
    Michael Schaefer, J"org Weule, and Eric Youngdale.
 
-   Copyright 1992 - 2010 Kai Makisara
+   Copyright 1992 - 2016 Kai Makisara
    email [e-mail]
 
    Some small formal changes - aeb, 950809
@@ -17,7 +17,7 @@ 
    Last modified: 18-JAN-1998 Richard Gooch <[e-mail]> Devfs support
  */
 
-static const char *verstr = "20101219";
+static const char *verstr = "20160104";
 
 #include <linux/module.h>
 
@@ -3296,7 +3296,10 @@ 
 #define PP_OFF_RESERVED        7
 
 #define PP_BIT_IDP             0x20
+#define PP_BIT_FDP             0x80
 #define PP_MSK_PSUM_MB         0x10
+#define PP_MSK_PSUM_UNITS      0x18
+#define PP_MSK_POFM            0x04
 
 /* Get the number of partitions on the tape. As a side effect reads the
    mode page into the tape buffer. */
@@ -3322,6 +3325,29 @@ 
 }
 
 
+static int format_medium(struct scsi_tape *STp, int format)
+{
+	int result = 0;
+	int timeout = STp->long_timeout;
+	unsigned char scmd[MAX_COMMAND_SIZE];
+	struct st_request *SRpnt;
+
+	memset(scmd, 0, MAX_COMMAND_SIZE);
+	scmd[0] = FORMAT_UNIT;
+	scmd[2] = format;
+	if (STp->immediate) {
+		scmd[1] |= 1;		/* Don't wait for completion */
+		timeout = STp->device->request_queue->rq_timeout;
+	}
+	DEBC_printk(STp, "Sending FORMAT MEDIUM\n");
+	SRpnt = st_do_scsi(NULL, STp, scmd, 0, DMA_NONE,
+			   timeout, MAX_RETRIES, 1);
+	if (!SRpnt)
+		result = STp->buffer->syscall_result;
+	return result;
+}
+
+
 /* Partition the tape into two partitions if size > 0 or one partition if
    size == 0.
 
@@ -3340,11 +3366,15 @@ 
    and 10 when 1 partition is defined (information from Eric Lee Green). This is
    is acceptable also to some other old drives and enforced if the first partition
    size field is used for the first additional partition size.
+
+   For drives that advertize SCSI-3 or newer, use the SSC-3 methods.
  */
 static int partition_tape(struct scsi_tape *STp, int size)
 {
 	int result;
+	bool scsi3 = STp->device->scsi_level >= SCSI_3,  needs_format = false;
 	int pgo, psd_cnt, psdo;
+	int psum = PP_MSK_PSUM_MB, units = 0;
 	unsigned char *bp;
 
 	result = read_mode_page(STp, PART_PAGE, 0);
@@ -3357,11 +3387,58 @@ 
 	pgo = MODE_HEADER_LENGTH + bp[MH_OFF_BDESCS_LENGTH];
 	DEBC_printk(STp, "Partition page length is %d bytes.\n",
 		    bp[pgo + MP_OFF_PAGE_LENGTH] + 2);
+	DEBC_printk(STp, "PP: max %u, add %u, xdp %u, psum %02x, pofmetc %u, "
+		    "rec %02x, units %02x, sizes: %u %u\n",
+		    bp[pgo + PP_OFF_MAX_ADD_PARTS],
+		    bp[pgo + PP_OFF_NBR_ADD_PARTS],
+		    (bp[pgo + PP_OFF_FLAGS] & 0xe0) >> 5,
+		    (bp[pgo + PP_OFF_FLAGS] & 0x18) >> 3,
+		    bp[pgo + PP_OFF_FLAGS] & 0x07,
+		    bp[pgo + 5],
+		    bp[pgo + PP_OFF_PART_UNITS],
+		    bp[pgo + 8] * 256 + bp[pgo + 9],
+		    bp[pgo + 10] * 256 + bp[pgo + 11]);
+	DEBC_printk(STp, "MP: %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x\n",
+		    bp[pgo], bp[pgo+1], bp[pgo+2], bp[pgo+3], bp[pgo+4], bp[pgo+5],
+		    bp[pgo+6], bp[pgo+7], bp[pgo+8], bp[pgo+9], bp[pgo+10], bp[pgo+11]);
+
+	if (scsi3) {
+		needs_format = (bp[pgo + PP_OFF_FLAGS] & PP_MSK_POFM) != 0;
+		if (needs_format && size == 0) {
+			/* No need to write the mode page in this case */
+			result = format_medium(STp, 0);
+			goto out;
+		}
+
+		psd_cnt = size > 0 ? 2 : 1;
+		if ((bp[pgo + PP_OFF_FLAGS] & PP_MSK_PSUM_UNITS) == PP_MSK_PSUM_UNITS) {
+			/* Use units scaling for large partitions if the device suggests
+			   it and no precision lost. Required for IBM TS1140/50 drives
+			   that don't support MB units. */
+			if (size >= 1000 && (size % 1000) == 0) {
+				size /= 1000;
+				psum = PP_MSK_PSUM_UNITS;
+				units = 9; /* GB */
+			}
+		}
+		/* Try it anyway if too large to specify in MB */
+		if (psum == PP_MSK_PSUM_MB && size >= 65534) {
+				size /= 1000;
+				psum = PP_MSK_PSUM_UNITS;
+				units = 9;  /* GB */
+		}
+	} else
+		psd_cnt = (bp[pgo + MP_OFF_PAGE_LENGTH] + 2 -
+			   PART_PAGE_FIXED_LENGTH) / 2;
+
+	if (size >= 65534) { /* Does not fit into two bytes */
+		result = -EINVAL;
+		goto out;
+	}
 
-	psd_cnt = (bp[pgo + MP_OFF_PAGE_LENGTH] + 2 - PART_PAGE_FIXED_LENGTH) / 2;
 	psdo = pgo + PART_PAGE_FIXED_LENGTH;
-	if (psd_cnt > bp[pgo + PP_OFF_MAX_ADD_PARTS]) {
-		bp[psdo] = bp[psdo + 1] = 0xff;  /* Rest of the tape */
+	if (scsi3 || psd_cnt > bp[pgo + PP_OFF_MAX_ADD_PARTS]) {
+		bp[psdo] = bp[psdo + 1] = 0xff;  /* Rest of the tape to partition 0 */
 		psdo += 2;
 	}
 	memset(bp + psdo, 0, bp[pgo + PP_OFF_NBR_ADD_PARTS] * 2);
@@ -3375,6 +3452,11 @@ 
 		if (psd_cnt <= bp[pgo + PP_OFF_MAX_ADD_PARTS])
 		    bp[pgo + MP_OFF_PAGE_LENGTH] = 6;
 		DEBC_printk(STp, "Formatting tape with one partition.\n");
+	} else if (size == 1 && units == 0) {
+		bp[pgo + PP_OFF_NBR_ADD_PARTS] = 1;
+		if (psd_cnt <= bp[pgo + PP_OFF_MAX_ADD_PARTS])
+		    bp[pgo + MP_OFF_PAGE_LENGTH] = 6;
+		DEBC_printk(STp, "Formatting tape with two partitions (FDP).\n");
 	} else {
 		bp[psdo] = (size >> 8) & 0xff;
 		bp[psdo + 1] = size & 0xff;
@@ -3382,18 +3464,48 @@ 
 		if (bp[pgo + MP_OFF_PAGE_LENGTH] < 8)
 		    bp[pgo + MP_OFF_PAGE_LENGTH] = 8;
 		DEBC_printk(STp, "Formatting tape with two partitions "
-			    "(1 = %d MB).\n", size);
+			    "(1 = %d MB).\n",
+			    units > 0 ? size * 1000 : size);
 	}
 	bp[pgo + PP_OFF_PART_UNITS] = 0;
 	bp[pgo + PP_OFF_RESERVED] = 0;
-	bp[pgo + PP_OFF_FLAGS] = PP_BIT_IDP | PP_MSK_PSUM_MB;
+	if (size != 1 || units != 0) {
+		bp[pgo + PP_OFF_FLAGS] = PP_BIT_IDP | psum |
+			(bp[pgo + PP_OFF_FLAGS] & 0x07);
+		bp[pgo + PP_OFF_PART_UNITS] = units;
+	} else
+		bp[pgo + PP_OFF_FLAGS] = PP_BIT_FDP |
+			(bp[pgo + PP_OFF_FLAGS] & 0x1f);
+	bp[pgo + MP_OFF_PAGE_LENGTH] = 6 + psd_cnt * 2;
+
+	DEBC_printk(STp, "Sent partition page length is %d bytes. needs_format: %d\n",
+		    bp[pgo + MP_OFF_PAGE_LENGTH] + 2, needs_format);
+	DEBC_printk(STp, "PP: max %u, add %u, xdp %u, psum %02x, pofmetc %u, "
+		    "rec %02x, units %02x, sizes: %u %u\n",
+		    bp[pgo + PP_OFF_MAX_ADD_PARTS],
+		    bp[pgo + PP_OFF_NBR_ADD_PARTS],
+		    (bp[pgo + PP_OFF_FLAGS] & 0xe0) >> 5,
+		    (bp[pgo + PP_OFF_FLAGS] & 0x18) >> 3,
+		    bp[pgo + PP_OFF_FLAGS] & 0x07,
+		    bp[pgo + 5],
+		    bp[pgo + PP_OFF_PART_UNITS],
+		    bp[pgo + 8] * 256 + bp[pgo + 9],
+		    bp[pgo + 10] * 256 + bp[pgo + 11]);
+	DEBC_printk(STp, "MP: %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x\n",
+		    bp[pgo], bp[pgo+1], bp[pgo+2], bp[pgo+3], bp[pgo+4], bp[pgo+5],
+		    bp[pgo+6], bp[pgo+7], bp[pgo+8], bp[pgo+9], bp[pgo+10], bp[pgo+11]);
 
 	result = write_mode_page(STp, PART_PAGE, 1);
+
+	if (!result && needs_format)
+		result = format_medium(STp, 1);
+
 	if (result) {
 		st_printk(KERN_INFO, STp, "Partitioning of tape failed.\n");
 		result = (-EIO);
 	}
 
+out:
 	return result;
 }
 
@@ -3570,7 +3682,7 @@ 
 				retval = (-EINVAL);
 				goto out;
 			}
-			if ((i = st_int_ioctl(STp, MTREW, 0)) < 0 ||
+			if ((i = do_load_unload(STp, file, 1)) < 0 ||
 			    (i = partition_tape(STp, mtc.mt_count)) < 0) {
 				retval = i;
 				goto out;
@@ -3581,7 +3693,7 @@ 
 				STp->ps[i].last_block_valid = 0;
 			}
 			STp->partition = STp->new_partition = 0;
-			STp->nbr_partitions = 1;	/* Bad guess ?-) */
+			STp->nbr_partitions = mtc.mt_count > 0 ? 2 : 1;
 			STps->drv_block = STps->drv_file = 0;
 			retval = 0;
 			goto out;