Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-02-04 Thread Laurence Oberman 

Kai's latest patch passes all my tests on the DAT DSS drive
Fails on the older LTO3 as it should. (un-partionable)
I don't have the new LTO5 yet, arrives end of week I am told.

Testing log
---
[root@srp-server ~]# uname -a
Linux srp-server 4.4.0 #1 SMP Thu Jan 28 15:06:45 EST 2016 x86_64 x86_64 x86_64 
GNU/Linux

Storage Changer /dev/sg3:1 Drives, 6 Slots ( 0 Import/Export )
Data Transfer Element 0:Full (Storage Element 2 Loaded)
  Storage Element 1:Full
  Storage Element 2:Empty
  Storage Element 3:Full
  Storage Element 4:Full
  Storage Element 5:Full
  Storage Element 6:Empty

[root@srp-server home]# mtx -f /dev/sg3 unload 2 0
Unloading drive 0 into Storage Element 2...done

[root@srp-server home]# mtx -f /dev/sg3 load 3 0
Loading media from Storage Element 3 into drive 0...done

[root@srp-server home]# sg_map -st -i
/dev/sg2  /dev/nst0  HPDAT72X6   B409
/dev/sg3  HPDAT72X6   B409

[root@srp-server home]# mt -f /dev/st0 stsetoption can-partitions

[root@srp-server home]# mt -f /dev/st0 mkpartition 1

Tape screen shows Format

Completed with no errors and I can set to a specific partition

Feb 04 13:42:27 srp-server kernel: st: Unloaded.
Feb 04 13:43:57 srp-server kernel: st: Version 20160203, fixed bufsize 32768, 
s/g segs 256
Feb 04 13:43:57 srp-server kernel: st: Debugging enabled debug_flag = 1
Feb 04 13:43:57 srp-server kernel: st 6:0:1:0: Attached scsi tape st0
Feb 04 13:43:57 srp-server kernel: st 6:0:1:0: st0: try direct i/o: yes 
(alignment 4 B)

Feb 04 13:48:30 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 
bytes.
Feb 04 13:48:30 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Feb 04 13:48:30 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 
0, drv buffer: 1
Feb 04 13:48:30 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer 
size: 4096 (1 blocks).
Feb 04 13:48:30 srp-server kernel: st 6:0:1:0: [st0] Updating partition number 
in status.
Feb 04 13:48:30 srp-server kernel: st 6:0:1:0: [st0] Got tape pos. blk 0 part 0.
Feb 04 13:48:30 srp-server kernel: st 6:0:1:0: [st0] Mode 0 options: buffer 
writes: 1, async writes: 1, read ahead: 1
Feb 04 13:48:30 srp-server kernel: st 6:0:1:0: [st0] can bsr: 1, two FMs: 
0, fast mteom: 0, auto lock: 0,
Feb 04 13:48:30 srp-server kernel: st 6:0:1:0: [st0] defs for wr: 0, no 
block limits: 0, partitions: 1, s2 log: 0
Feb 04 13:48:30 srp-server kernel: st 6:0:1:0: [st0] sysv: 0 nowait: 0 
sili: 0 nowait_filemark: 0
Feb 04 13:48:30 srp-server kernel: st 6:0:1:0: [st0] debugging: 1
Feb 04 13:48:30 srp-server kernel: st 6:0:1:0: [st0] Rewinding tape.

Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 
bytes.
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 
0, drv buffer: 1
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer 
size: 4096 (1 blocks).
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] Loading tape.
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] Error: 802, cmd: 0 0 0 
0 0 0
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] Sense Key : Unit Attention 
[current]
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] Add. Sense: Not ready to 
ready change, medium may have changed
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 
bytes.
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 
0, drv buffer: 1
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer 
size: 4096 (1 blocks).
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] Partition page length is 
10 bytes.
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] PP: max 1, add 0, xdp 0, 
psum 02, pofmetc 0, rec 03, units 00, sizes: 0 65535
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] MP: 11 08 01 00 10 03 00 
00 00 00 ff ff
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] psd_cnt 1, max.parts 1, 
nbr_parts 0
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] Formatting tape with two 
partitions (1 = 1 MB).
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] Sent partition page length 
is 10 bytes. needs_format: 0
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] PP: max 1, add 1, xdp 1, 
psum 02, pofmetc 0, rec 03, units 00, sizes: 1 65535
Feb 04 13:48:42 srp-server kernel: st 6:0:1:0: [st0] MP: 11 08 01 01 30 03 00 
00 27 10 ff ff


Tested-by: Laurence Oberman 

Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

- Original Message -
From: "Douglas Gilbert" 
To: "Kai

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-02-04 Thread Kai Mäkisara (Kolumbus) 

> On 4.2.2016, at 3.43, Seymour, Shane M  wrote:
> 
> Hi Kai,
> 
> Tested with patched kernel 4.5.0-rc2-next-20160202+. It's looking good 
> everything partition related passed with DDS5 and LTO6. You can definitely 
> add me as a tested-by. I did find one issue below but it's not related to the 
> partitioning changes.
> 
Thanks for testing. It would be interesting to get confirmation from a LTO-5 
user that partitioning
works. Even without that I will make the final patch within a few days (remove 
some debugging
and update the documentation).

...
> I did find one issue in testing unrelated to the changes, the tell option 
> didn't work with my LTO-6 drive:
> 
> # ./mt -f /dev/st0 tell
> /dev/st0: Input/output error
> 
> [ 2045.974642] st 3:0:0:0: [st0] Block limits 1 - 16777215 bytes.
> [ 2045.975221] st 3:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 
> 8
> [ 2045.975224] st 3:0:0:0: [st0] Density 5a, tape length: 0, drv buffer: 1
> [ 2045.975226] st 3:0:0:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
> [ 2045.975718] st 3:0:0:0: [st0] Error: 802, cmd: 34 1 0 0 0 0
> [ 2045.975723] st 3:0:0:0: [st0] Sense Key : Illegal Request [current]
> [ 2045.975726] st 3:0:0:0: [st0] Add. Sense: Invalid field in cdb
> [ 2045.975729] st 3:0:0:0: [st0]  Can't read tape position.
> [ 2045.975857] st 3:0:0:0: [st0] Rewinding tape.
> 
> I believe that in get_location() we're doing this:
> 
> static int get_location(struct scsi_tape *STp, unsigned int *block, int 
> *partition,
>int logical)
> {
>int result;
>unsigned char scmd[MAX_COMMAND_SIZE];
>struct st_request *SRpnt;
> 
>if (STp->ready != ST_READY)
>return (-EIO);
> 
>memset(scmd, 0, MAX_COMMAND_SIZE);
>if ((STp->device)->scsi_level < SCSI_2) {
>scmd[0] = QFA_REQUEST_BLOCK;
>scmd[4] = 3;
>} else {
>scmd[0] = READ_POSITION;
>if (!logical && !STp->scsi2_logical)
>scmd[1] = 1; <<
>}
> 
> When called from the ioctl that the tell option uses the variable logical is 
> passed in as 0 (from what I could see everything else sets it to 1). For a 
> READ_POSITION the drive I'm using only supports 0, 6, or 8 in the service 
> action field of the second byte:
> 
I think you have not set the scsi2_logical option bit with mt or stinit or some 
other tool.
The default of device-specific addresses is a historical mistake but we have to 
live with
it. I don’t see this as a big problem because any user of current drives should 
enable
some driver options anyway.

Thanks,
Kai

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

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-02-04 Thread Emmanuel Florac 
Le Thu, 4 Feb 2016 19:54:55 +0200
"Kai Mäkisara (Kolumbus)"  écrivait:

> > Tested with patched kernel 4.5.0-rc2-next-20160202+. It's looking
> > good everything partition related passed with DDS5 and LTO6. You
> > can definitely add me as a tested-by. I did find one issue below
> > but it's not related to the partitioning changes. 
> Thanks for testing. It would be interesting to get confirmation from
> a LTO-5 user that partitioning works. Even without that I will make
> the final patch within a few days (remove some debugging and update
> the documentation).

I currently have one IBM LTO-4, one HP LTO-5 and one HP LTO-6 drives.
I'll try to run some tests tomorrow.

-- 

Emmanuel Florac |   Direction technique
|   Intellique
|   
|   +33 1 78 94 84 02

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

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-02-04 Thread Douglas Gilbert 

Hi,
With a HP Ultrium 3000 tape drive (LTO-5) and a HP C7975A
tape cartridge (LTO-5 and partition capable) and mt as
patched by Shane:

# lsscsi -g
[1:0:0:0]  diskATAST3320620AS  K /dev/sda   /dev/sg0
[6:0:0:0]  tapeHP Ultrium 5-SCSI   Z64D  /dev/st0   /dev/sg1

# sg_read_attr -s 3 /dev/sg1
Partition number list:
  First partition number: 0
  Number of partitions available: 1

# mt -f /dev/st0 stsetoption debug
# mt -f /dev/st0 stsetoption can-partitions
# mt -f /dev/st0 mkpartition 1

The following was cut and pasted from /var/log/messages

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

# sg_read_attr -s 3 /dev/sg1
Partition number list:
  First partition number: 0
  Number of partitions available: 2

Looks good.

Tested-by: Douglas Gilbert 


On 16-02-04 12:54 PM, "Kai Mäkisara (Kolumbus)" wrote:



On 4.2.2016, at 3.43, Seymour, Shane M  wrote:

Hi Kai,

Tested with patched kernel 4.5.0-rc2-next-20160202+. It's looking good 
everything partition related passed with DDS5 and LTO6. You can definitely add 
me as a tested-by. I did find one issue below but it's not related to the 
partitioning changes.


Thanks for testing. It would be interesting to get confirmation from a LTO-5 
user that partitioning
works. Even without that I will make the final patch within a few days (remove 
some debugging
and update the documentation).

...

I did find one issue in testing unrelated to the changes, the tell option 
didn't work with my LTO-6 drive:

# ./mt -f /dev/st0 tell
/dev/st0: Input/output error

[ 2045.974642] st 3:0:0:0: [st0] Block limits 1 - 16777215 bytes.
[ 2045.975221] st 3:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 2045.975224] st 3:0:0:0: [st0] Density 5a, tape length: 0, drv buffer: 1
[ 2045.975226] st 3:0:0:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
[ 2045.975718] st 3:0:0:0: [st0] Error: 802, cmd: 34 1 0 0 0 0
[ 2045.975723] st 3:0:0:0: [st0] Sense Key : Illegal Request [current]
[ 2045.975726] st 3:0:0:0: [st0] Add. Sense: Invalid field in cdb
[ 2045.975729] st 3:0:0:0: [st0]  Can't read tape position.
[ 2045.975857] st 3:0:0:0: [st0] Rewinding tape.

I believe that in get_location() we're doing this:

static int get_location(struct scsi_tape *STp, unsigned int *block, int 
*partition,
int logical)
{
int result;
unsigned char scmd[MAX_COMMAND_SIZE];
struct st_request *SRpnt;

if (STp->ready != ST_READY)
return (-EIO);

memset(scmd, 0, MAX_COMMAND_SIZE);
if ((STp->device)->scsi_level < SCSI_2) {
scmd[0] = QFA_REQUEST_BLOCK;
scmd[4] = 3;
} else {
scmd[0] = READ_POSITION;
if (!logical && !STp->scsi2_logical)
scmd[1] = 1; <<
}

When called from the ioctl that the tell option uses the variable logical is 
passed in as 0 (from what I could see everything else sets it to 1). For a 
READ_POSITION the drive I'm using only supports 0, 6, or 8 in the service 
action field of the second byte:


I think you have not set the scsi2_logical option bit with mt or stinit or some 
other tool.
The default of device-specific addresses is a historical mistake but we have to 
live with
it. I don’t see this as a big problem because any user of current drives should 
enable
some driver options anyway.

Thanks,
Kai

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



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

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-02-03 Thread Kai Makisara 
On Wednesday 2016-02-03 04:18, Seymour, Shane M wrote:

...>
># mt -f /dev/st2 mkpartition 200G
>
>Fails and doesn't print all of the messages related for partitioning:
>
>[ 3514.306582] st 8:0:0:0: [st2] Block limits 1 - 16777215 bytes.
>[ 3514.307126] st 8:0:0:0: [st2] Mode sense. Length 11, medium 0, WBS 10, BLL 8
>[ 3514.307129] st 8:0:0:0: [st2] Density 5a, tape length: 0, drv buffer: 1
>[ 3514.307132] st 8:0:0:0: [st2] Block size: 0, buffer size: 4096 (1 blocks).
>[ 3514.307133] st 8:0:0:0: [st2] Updating partition number in status.
>[ 3514.308133] st 8:0:0:0: [st2] Got tape pos. blk 0 part 0.
>[ 3514.308159] st 8:0:0:0: [st2] Loading tape.
>[ 3514.323173] st 8:0:0:0: [st2] Block limits 1 - 16777215 bytes.
>[ 3514.323624] st 8:0:0:0: [st2] Mode sense. Length 11, medium 0, WBS 10, BLL 8
>[ 3514.323628] st 8:0:0:0: [st2] Density 5a, tape length: 0, drv buffer: 1
>[ 3514.323632] st 8:0:0:0: [st2] Block size: 0, buffer size: 4096 (1 blocks).
>[ 3514.324507] st 8:0:0:0: [st2] Partition page length is 16 bytes.
>[ 3514.324513] st 8:0:0:0: [st2] PP: max 3, add 0, xdp 1, psum 03, pofmetc 4, 
>rec 03, units 09, sizes: 2620 0
>[ 3514.324518] st 8:0:0:0: [st2] MP: 11 0e 03 00 3c 03 09 00 0a 3c 00 00
>[ 3514.324521] st 8:0:0:0: [st2] Sending FORMAT MEDIUM
>[ 3519.097142] st 8:0:0:0: [st2] Rewinding tape.
>
>The only way that can happen is if it thinks it should be clearing the 
>partitions in this code:
>
>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 when clearing 
> partitioning */
>result = format_medium(STp, 0);
>goto out;
>}
>
Yes. This is a mt bug. The ioctl argument is zero. Note that the mt 
definition may also be a bit misleading: appending G means that the 
number is multiplied by 1024^3. For mkpart the unit is already MB, 
so you tried to make a very big partition :-)

>Since we can format and exit by juming to out here we probably need this in 
>there as well before the goto:
>
>   DEBC_printk(STp, "Formatting tape with one partition.\n");
>
>Something appears to have dropped the size to be zero. Should the mt command 
>in mt-st reject anything that could become zero with an error? I haven't 
>looked at the command to see why it dropped the value to 0 (I am assuming 
>that's where it happened). There should probably be an error or something 
>printed otherwise someone will assume that the partitioning worked 
>successfully when in fact the partitions were cleared.
>
>If instead I ask for 200 instead of 200G I get the following:
>
>[ 3875.588006] st 8:0:0:0: [st2] Block limits 1 - 16777215 bytes.
>[ 3875.588617] st 8:0:0:0: [st2] Mode sense. Length 11, medium 0, WBS 10, BLL 8
>[ 3875.588620] st 8:0:0:0: [st2] Density 5a, tape length: 0, drv buffer: 1
>[ 3875.588622] st 8:0:0:0: [st2] Block size: 0, buffer size: 4096 (1 blocks).
>[ 3875.588638] st 8:0:0:0: [st2] Loading tape.
>[ 3875.603659] st 8:0:0:0: [st2] Block limits 1 - 16777215 bytes.
>[ 3875.604113] st 8:0:0:0: [st2] Mode sense. Length 11, medium 0, WBS 10, BLL 8
>[ 3875.604117] st 8:0:0:0: [st2] Density 5a, tape length: 0, drv buffer: 1
>[ 3875.604121] st 8:0:0:0: [st2] Block size: 0, buffer size: 4096 (1 blocks).
>[ 3875.605052] st 8:0:0:0: [st2] Partition page length is 16 bytes.
>[ 3875.605058] st 8:0:0:0: [st2] PP: max 3, add 0, xdp 1, psum 03, pofmetc 4, 
>rec 03, units 09, sizes: 2620 0
>[ 3875.605063] st 8:0:0:0: [st2] MP: 11 0e 03 00 3c 03 09 00 0a 3c 00 00
>[ 3875.605066] st 8:0:0:0: [st2] psd_cnt 2, max.parts 3, nbr_parts 0
>[ 3875.605069] st 8:0:0:0: [st2] Formatting tape with two partitions (1 = 200 
>MB).
>[ 3875.605072] st 8:0:0:0: [st2] Sent partition page length is 12 bytes. 
>needs_format: 1
>[ 3875.605076] st 8:0:0:0: [st2] PP: max 3, add 1, xdp 1, psum 02, pofmetc 4, 
>rec 03, units 00, sizes: 200 0
>[ 3875.605080] st 8:0:0:0: [st2] MP: 11 0a 03 01 34 03 00 00 00 c8 00 00
>[ 3875.605952] st 8:0:0:0: [st2] Error: 802, cmd: 15 10 0 0 18 0
>[ 3875.605957] st 8:0:0:0: [st2] Sense Key : Illegal Request [current]
>[ 3875.605961] st 8:0:0:0: [st2] Add. Sense: Invalid field in parameter list
>[ 3875.605964] st 8:0:0:0: [st2] Partitioning of tape failed.
>[ 3875.606087] st 8:0:0:0: [st2] Rewinding tape.
>
>Since a positive number sets the size of the second partition I would have 
>expected the sizes to be 0x and 200 not 200 and 0.
> 
># mt -f /dev/st2 mkpartition 2000
>
>[ 3957.373197] st 8:0:0:0: [st2] Block limits 1 - 16777215 bytes.
>[ 3957.373729] st 8:0:0:0: [st2] Mode sense. Length 11, medium 0, WBS 10, BLL 8
>[ 3957.373732] st 8:0:0:0: [st2] Density 5a, tape length: 0, drv buffer: 1
>[ 3957.373734] st 8:0:0:0: [st2] Block size: 0, buffer size: 4096 (1 blocks).
>[ 3957.373750] st 8:0:0:0: [st2] Loading tape.
>[ 3957.388599] st 8:0:0:0: [st2] Block limits 1 - 16777215 bytes.
>[

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-02-02 Thread Laurence Oberman 
Hello

Finally got my firmware on my DAT updated.
Using Kai's latest patch I validated the patch on my DAT driver as well
Thanks to Shane for providing the correct mt code, as that was also one of my 
problems besides firmware.

[root@srp-server mt-st-1.1-patched]# ./mt -f /dev/st0 stsetoption can-partitions
[root@srp-server mt-st-1.1-patched]# ./mt -f /dev/st0 mkpartition 1000

Took almost 6 minutes to partition this old DDS

Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 
0, drv buffer: 1
Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer 
size: 4096 (1 blocks).
Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] Mode 0 options: buffer 
writes: 1, async writes: 1, read ahead: 1
Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] can bsr: 1, two FMs: 
0, fast mteom: 0, auto lock: 0,
Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] defs for wr: 0, no 
block limits: 0, partitions: 1, s2 log: 0
Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] sysv: 0 nowait: 0 
sili: 0 nowait_filemark: 0
Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] debugging: 1
Feb 02 22:25:10 srp-server kernel: st 6:0:1:0: [st0] Rewinding tape.

Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 
bytes.
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 
0, drv buffer: 1
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer 
size: 4096 (1 blocks).
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Updating partition number 
in status.
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Got tape pos. blk 0 part 0.
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Loading tape.
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Error: 802, cmd: 0 0 0 
0 0 0
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Sense Key : Unit Attention 
[current] 
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Add. Sense: Not ready to 
ready change, medium may have changed
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 
bytes.
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 
0, drv buffer: 1
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer 
size: 4096 (1 blocks).
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Partition page length is 
10 bytes.
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] PP: max 1, add 0, xdp 0, 
psum 02, pofmetc 0, rec 03, units 00, sizes: 0 65535
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] MP: 11 08 01 00 10 03 00 
00 00 00 ff ff
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] psd_cnt 1, max.parts 1, 
nbr_parts 0
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Formatting tape with two 
partitions (1 = 1000 MB).
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] Sent partition page length 
is 10 bytes. needs_format: 0
Feb 02 22:25:24 srp-server kernel: st 6:0:1:0: [st0] PP: max 1, add 1, xdp 1, 
psum 02, pofmetc 0, rec 03, units 00, sizes: 1000 65535
Feb 02 22:31:45 srp-server kernel: st 6:0:1:0: [st0] Rewinding tape.

I will retest with Shane's latest additions he just sent after first testing 
with Kai's latest patch on my LTO5.
(here's hoping I dont have to update the f/w on that one)


Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

- Original Message -
From: "Kai Mäkisara (Kolumbus)" 
To: "Shane M Seymour" 
Cc: "Laurence Oberman" , "Emmanuel Florac" 
, "Laurence Oberman" , 
linux-scsi@vger.kernel.org
Sent: Monday, February 1, 2016 1:43:26 PM
Subject: Re: What partition should the MTMKPART argument specify? Was: Re: st 
driver doesn't seem to grok LTO partitioning


> On 1.2.2016, at 8.31, Seymour, Shane M  wrote:
> 
> Hi Kai,
> 
> Thanks for the changes the HPE DAT72 DDS5 drive now works as expected:
> 
Good. Thanks for testing.

...
> 
> I'm asking around again one final time to see if I can lay my hands on a LTO5 
> or greater drive so I can test LTO partitioning as well.
> 
> The only other thing I can think of (I'm not sure if this is an improvement 
> or not) is if bp[pgo + PP_OFF_MAX_ADD_PARTS] + bp[pgo + PP_OFF_NBR_ADD_PARTS] 
> (max.parts and nbr_parts in the debug message) is zero just return -EINVAL 
> unless you know of any take drives that report them both as 0 but can be 
> partitioned? That is after this:
> 
>DEBC_printk(STp, "psd_cnt %d, max.parts %d, nbr_parts %d\n",
>psd_cnt, bp[pgo + PP_OFF_MAX_ADD_PARTS],
>

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-02-02 Thread Seymour, Shane M 
Hi Kai,

I've done more tested. Some stuff didn't work and I've got some suggested 
changes (there are two changes to the patch and one for the mt command). 
Testing results first:

# echo 1 > /sys/bus/scsi/drivers/st/debug_flag
# mt -f /dev/st2 stsetoption can-partitions
# mt -f /dev/st1 stsetoption can-partitions
# mt -f /dev/st0 stsetoption can-partitions

Expect to fail LTO3:

# mt -f /dev/st0 mkpartition 500
/dev/st0: Input/output error

[ 3197.901583] st 5:0:1:0: [st0] Block limits 1 - 16777215 bytes.
[ 3197.903613] st 5:0:1:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 3197.903618] st 5:0:1:0: [st0] Density 44, tape length: 0, drv buffer: 1
[ 3197.903622] st 5:0:1:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
[ 3197.903625] st 5:0:1:0: [st0] Updating partition number in status.
[ 3197.906406] st 5:0:1:0: [st0] Got tape pos. blk 0 part 0.
[ 3197.906429] st 5:0:1:0: [st0] Loading tape.
[ 3197.929484] st 5:0:1:0: [st0] Block limits 1 - 16777215 bytes.
[ 3197.931518] st 5:0:1:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 3197.931524] st 5:0:1:0: [st0] Density 44, tape length: 0, drv buffer: 1
[ 3197.931527] st 5:0:1:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
[ 3197.933840] st 5:0:1:0: [st0] Partition page length is 10 bytes.
[ 3197.933846] st 5:0:1:0: [st0] PP: max 0, add 0, xdp 0, psum 03, pofmetc 0, 
rec 03, units 09, sizes: 400 65535
[ 3197.933851] st 5:0:1:0: [st0] MP: 11 08 00 00 18 03 09 00 01 90 ff ff
[ 3197.933854] st 5:0:1:0: [st0] psd_cnt 1, max.parts 0, nbr_parts 0
[ 3197.933857] st 5:0:1:0: [st0] Formatting tape with two partitions (1 = 500 
MB).
[ 3197.933860] st 5:0:1:0: [st0] Sent partition page length is 10 bytes. 
needs_format: 0
[ 3197.933865] st 5:0:1:0: [st0] PP: max 0, add 1, xdp 1, psum 02, pofmetc 0, 
rec 03, units 00, sizes: 65535 500
[ 3197.933869] st 5:0:1:0: [st0] MP: 11 08 00 01 30 03 00 00 ff ff 01 f4
[ 3197.937706] st 5:0:1:0: [st0] Error: 802, cmd: 15 10 0 0 16 0
[ 3197.937712] st 5:0:1:0: [st0] Sense Key : Illegal Request [current]
[ 3197.937716] st 5:0:1:0: [st0] Add. Sense: Invalid field in parameter list
[ 3197.937719] st 5:0:1:0: [st0] Partitioning of tape failed.
[ 3197.937847] st 5:0:1:0: [st0] Rewinding tape.

Works DDS5:

# mt -f /dev/st1 mkpartition 500

[ 3241.355474] st 6:0:3:0: [st1] Block limits 1 - 16777215 bytes.
[ 3241.355775] st 6:0:3:0: [st1] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 3241.355779] st 6:0:3:0: [st1] Density 47, tape length: 0, drv buffer: 1
[ 3241.355783] st 6:0:3:0: [st1] Block size: 0, buffer size: 4096 (1 blocks).
[ 3241.355785] st 6:0:3:0: [st1] Updating partition number in status.
[ 3241.356385] st 6:0:3:0: [st1] Got tape pos. blk 0 part 0.
[ 3241.356397] st 6:0:3:0: [st1] Loading tape.
[ 3241.357249] st 6:0:3:0: [st1] Block limits 1 - 16777215 bytes.
[ 3241.357540] st 6:0:3:0: [st1] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 3241.357544] st 6:0:3:0: [st1] Density 47, tape length: 0, drv buffer: 1
[ 3241.357547] st 6:0:3:0: [st1] Block size: 0, buffer size: 4096 (1 blocks).
[ 3241.357882] st 6:0:3:0: [st1] Partition page length is 10 bytes.
[ 3241.357887] st 6:0:3:0: [st1] PP: max 1, add 1, xdp 0, psum 02, pofmetc 0, 
rec 03, units 00, sizes: 500 65535
[ 3241.357892] st 6:0:3:0: [st1] MP: 11 08 01 01 10 03 00 00 01 f4 ff ff
[ 3241.357895] st 6:0:3:0: [st1] psd_cnt 1, max.parts 1, nbr_parts 1
[ 3241.357898] st 6:0:3:0: [st1] Formatting tape with two partitions (1 = 500 
MB).
[ 3241.357901] st 6:0:3:0: [st1] Sent partition page length is 10 bytes. 
needs_format: 0
[ 3241.357906] st 6:0:3:0: [st1] PP: max 1, add 1, xdp 1, psum 02, pofmetc 0, 
rec 03, units 00, sizes: 500 65535
[ 3241.357910] st 6:0:3:0: [st1] MP: 11 08 01 01 30 03 00 00 01 f4 ff ff
[ 3464.721058] st 6:0:3:0: [st1] Rewinding tape.

# mt -f /dev/st2 mkpartition 200G

Fails and doesn't print all of the messages related for partitioning:

[ 3514.306582] st 8:0:0:0: [st2] Block limits 1 - 16777215 bytes.
[ 3514.307126] st 8:0:0:0: [st2] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 3514.307129] st 8:0:0:0: [st2] Density 5a, tape length: 0, drv buffer: 1
[ 3514.307132] st 8:0:0:0: [st2] Block size: 0, buffer size: 4096 (1 blocks).
[ 3514.307133] st 8:0:0:0: [st2] Updating partition number in status.
[ 3514.308133] st 8:0:0:0: [st2] Got tape pos. blk 0 part 0.
[ 3514.308159] st 8:0:0:0: [st2] Loading tape.
[ 3514.323173] st 8:0:0:0: [st2] Block limits 1 - 16777215 bytes.
[ 3514.323624] st 8:0:0:0: [st2] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 3514.323628] st 8:0:0:0: [st2] Density 5a, tape length: 0, drv buffer: 1
[ 3514.323632] st 8:0:0:0: [st2] Block size: 0, buffer size: 4096 (1 blocks).
[ 3514.324507] st 8:0:0:0: [st2] Partition page length is 16 bytes.
[ 3514.324513] st 8:0:0:0: [st2] PP: max 3, add 0, xdp 1, psum 03, pofmetc 4, 
rec 03, units 09, sizes: 2620 0
[ 3514.324518] st 8:0:0:0: [st2] MP: 11 0e 03 00 3c 03 09 00 0a 3c 00 00
[ 3514.324521] st 8:0:0:0: [st2] Sending FORMAT MEDIUM
[ 3519.097142]

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-02-01 Thread Laurence Oberman 
The new patch did not work for me, but I chatted with Shane and I have his mt 
version. 
I will update my DAT to same firmware or newer than his and provide a second 
tested by.
I also expect my LTO5 to show up this week so will be ready for that.

Thanks everyone for keeping tapes alive

Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

- Original Message -
From: "Kai Mäkisara (Kolumbus)" 
To: "Shane M Seymour" 
Cc: "Laurence Oberman" , "Emmanuel Florac" 
, "Laurence Oberman" , 
linux-scsi@vger.kernel.org
Sent: Monday, February 1, 2016 1:43:26 PM
Subject: Re: What partition should the MTMKPART argument specify? Was: Re: st 
driver doesn't seem to grok LTO partitioning


> On 1.2.2016, at 8.31, Seymour, Shane M  wrote:
> 
> Hi Kai,
> 
> Thanks for the changes the HPE DAT72 DDS5 drive now works as expected:
> 
Good. Thanks for testing.

...
> 
> I'm asking around again one final time to see if I can lay my hands on a LTO5 
> or greater drive so I can test LTO partitioning as well.
> 
> The only other thing I can think of (I'm not sure if this is an improvement 
> or not) is if bp[pgo + PP_OFF_MAX_ADD_PARTS] + bp[pgo + PP_OFF_NBR_ADD_PARTS] 
> (max.parts and nbr_parts in the debug message) is zero just return -EINVAL 
> unless you know of any take drives that report them both as 0 but can be 
> partitioned? That is after this:
> 
>DEBC_printk(STp, "psd_cnt %d, max.parts %d, nbr_parts %d\n",
>psd_cnt, bp[pgo + PP_OFF_MAX_ADD_PARTS],
>bp[pgo + PP_OFF_NBR_ADD_PARTS]);
> 
> add (and also turn off the can-partitions option):
> 
>   if ((bp[pgo + PP_OFF_MAX_ADD_PARTS] + bp[pgo + PP_OFF_NBR_ADD_PARTS]) 
> == 0) {
>   DEBC_printk(STp, "Drive not partitionable - max.parts+nbr_parts 
> is 0\n");
>   STp->can_partitions = 0;
>   return -EINVAL;
>   }
> 
> I'm not especially fussed if you don't want to add that though.
> 
I thought about a test like this (only test maximum number) but decided not to 
add it. The reason was that
I did not want to change anything that has worked before. I quite trust that 
the current drives return sense
data instead of crashing and the end result for the user would be the same. 
However, one can argue that
returning EINVAL is better than EIO but does the user notice? If the common 
opinion is that a test like this
should be added, I am not against it. It can be added to the code for SCSI >=3 
where it does not risk
anything for the old drives.

IMHO, can_partitions should not be cleared based on the test. For example, 
trying to partition a LTO-4 tape
in a LTO-5 drive should not disable partitioning. (The mode page should return 
zero as maximum number of
partitions when a LTO-4 tape is inserted.)

Thanks,
Kai

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

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-02-01 Thread Seymour, Shane M 
Hi Kai,

> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of "Kai Mäkisara (Kolumbus)"
> Sent: Tuesday, February 02, 2016 5:43 AM
> To: Seymour, Shane M
> Cc: Laurence Oberman; Emmanuel Florac; Laurence Oberman; linux-
> s...@vger.kernel.org
> Subject: Re: What partition should the MTMKPART argument specify? Was:
> Re: st driver doesn't seem to grok LTO partitioning
> 
> 
> > On 1.2.2016, at 8.31, Seymour, Shane M 
> wrote:
> >
> > Hi Kai,
> >
> > Thanks for the changes the HPE DAT72 DDS5 drive now works as expected:
> >
> Good. Thanks for testing.
> 
> ...
> >
> > I'm asking around again one final time to see if I can lay my hands on a 
> > LTO5
> or greater drive so I can test LTO partitioning as well.
> >
> > The only other thing I can think of (I'm not sure if this is an improvement 
> > or
> not) is if bp[pgo + PP_OFF_MAX_ADD_PARTS] + bp[pgo +
> PP_OFF_NBR_ADD_PARTS] (max.parts and nbr_parts in the debug message)
> is zero just return -EINVAL unless you know of any take drives that report
> them both as 0 but can be partitioned? That is after this:
> >
> >DEBC_printk(STp, "psd_cnt %d, max.parts %d, nbr_parts %d\n",
> >psd_cnt, bp[pgo + PP_OFF_MAX_ADD_PARTS],
> >bp[pgo + PP_OFF_NBR_ADD_PARTS]);
> >
> > add (and also turn off the can-partitions option):
> >
> > if ((bp[pgo + PP_OFF_MAX_ADD_PARTS] + bp[pgo +
> PP_OFF_NBR_ADD_PARTS]) == 0) {
> > DEBC_printk(STp, "Drive not partitionable -
> max.parts+nbr_parts is 0\n");
> > STp->can_partitions = 0;
> > return -EINVAL;
> > }
> >
> > I'm not especially fussed if you don't want to add that though.
> >
> I thought about a test like this (only test maximum number) but decided not
> to add it. The reason was that I did not want to change anything that has
> worked before. I quite trust that the current drives return sense data instead
> of crashing and the end result for the user would be the same. However, one
> can argue that returning EINVAL is better than EIO but does the user notice?
> If the common opinion is that a test like this should be added, I am not
> against it. It can be added to the code for SCSI >=3 where it does not risk
> anything for the old drives.
> 
> IMHO, can_partitions should not be cleared based on the test. For example,
> trying to partition a LTO-4 tape in a LTO-5 drive should not disable 
> partitioning.
> (The mode page should return zero as maximum number of partitions when
> a LTO-4 tape is inserted.)

No problem, I didn't think of the case where you have a non-partitionable tape 
in
a drive that can do partitions. That case should have been obvious to me.

I may be able to lay my hands on a LTO5+ drive (only a small chance). Someone in
the US is checking is checking for me and will hook it up to the system I use 
for
testing tape stuff for me. I'll only have it for about a week if I'm able to 
get it.

Thanks
Shane

> 
> Thanks,
> Kai
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the
> body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-02-01 Thread Kai Mäkisara (Kolumbus) 

> On 1.2.2016, at 8.31, Seymour, Shane M  wrote:
> 
> Hi Kai,
> 
> Thanks for the changes the HPE DAT72 DDS5 drive now works as expected:
> 
Good. Thanks for testing.

...
> 
> I'm asking around again one final time to see if I can lay my hands on a LTO5 
> or greater drive so I can test LTO partitioning as well.
> 
> The only other thing I can think of (I'm not sure if this is an improvement 
> or not) is if bp[pgo + PP_OFF_MAX_ADD_PARTS] + bp[pgo + PP_OFF_NBR_ADD_PARTS] 
> (max.parts and nbr_parts in the debug message) is zero just return -EINVAL 
> unless you know of any take drives that report them both as 0 but can be 
> partitioned? That is after this:
> 
>DEBC_printk(STp, "psd_cnt %d, max.parts %d, nbr_parts %d\n",
>psd_cnt, bp[pgo + PP_OFF_MAX_ADD_PARTS],
>bp[pgo + PP_OFF_NBR_ADD_PARTS]);
> 
> add (and also turn off the can-partitions option):
> 
>   if ((bp[pgo + PP_OFF_MAX_ADD_PARTS] + bp[pgo + PP_OFF_NBR_ADD_PARTS]) 
> == 0) {
>   DEBC_printk(STp, "Drive not partitionable - max.parts+nbr_parts 
> is 0\n");
>   STp->can_partitions = 0;
>   return -EINVAL;
>   }
> 
> I'm not especially fussed if you don't want to add that though.
> 
I thought about a test like this (only test maximum number) but decided not to 
add it. The reason was that
I did not want to change anything that has worked before. I quite trust that 
the current drives return sense
data instead of crashing and the end result for the user would be the same. 
However, one can argue that
returning EINVAL is better than EIO but does the user notice? If the common 
opinion is that a test like this
should be added, I am not against it. It can be added to the code for SCSI >=3 
where it does not risk
anything for the old drives.

IMHO, can_partitions should not be cleared based on the test. For example, 
trying to partition a LTO-4 tape
in a LTO-5 drive should not disable partitioning. (The mode page should return 
zero as maximum number of
partitions when a LTO-4 tape is inserted.)

Thanks,
Kai

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

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-31 Thread Seymour, Shane M 
Hi Kai,

Thanks for the changes the HPE DAT72 DDS5 drive now works as expected:

# ./mt -f /dev/st1 stsetoption debug
# ./mt -f /dev/st1 stsetoption can-partitions
# ./mt -f /dev/st1 mkpartition 1000

[  980.241139] st 6:0:3:0: [st1] Block limits 1 - 16777215 bytes.
[  980.241481] st 6:0:3:0: [st1] Mode 0 options: buffer writes: 1, async 
writes: 1, read ahead: 1
[  980.241487] st 6:0:3:0: [st1] can bsr: 1, two FMs: 0, fast mteom: 0, 
auto lock: 0,
[  980.241490] st 6:0:3:0: [st1] defs for wr: 0, no block limits: 0, 
partitions: 0, s2 log: 0
[  980.241493] st 6:0:3:0: [st1] sysv: 0 nowait: 0 sili: 0 nowait_filemark: 0
[  980.241496] st 6:0:3:0: [st1] debugging: 1
[  980.241502] st 6:0:3:0: [st1] Rewinding tape.
[  986.785288] st 6:0:3:0: [st1] Block limits 1 - 16777215 bytes.
[  986.785658] st 6:0:3:0: [st1] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[  986.785663] st 6:0:3:0: [st1] Density 47, tape length: 0, drv buffer: 1
[  986.785666] st 6:0:3:0: [st1] Block size: 0, buffer size: 4096 (1 blocks).
[  986.785686] st 6:0:3:0: [st1] Mode 0 options: buffer writes: 1, async 
writes: 1, read ahead: 1
[  986.785690] st 6:0:3:0: [st1] can bsr: 1, two FMs: 0, fast mteom: 0, 
auto lock: 0,
[  986.785693] st 6:0:3:0: [st1] defs for wr: 0, no block limits: 0, 
partitions: 1, s2 log: 0
[  986.785696] st 6:0:3:0: [st1] sysv: 0 nowait: 0 sili: 0 nowait_filemark: 0
[  986.785699] st 6:0:3:0: [st1] debugging: 1
[  986.785703] st 6:0:3:0: [st1] Rewinding tape.
[  994.642650] st 6:0:3:0: [st1] Block limits 1 - 16777215 bytes.
[  994.643219] st 6:0:3:0: [st1] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[  994.643225] st 6:0:3:0: [st1] Density 47, tape length: 0, drv buffer: 1
[  994.643229] st 6:0:3:0: [st1] Block size: 0, buffer size: 4096 (1 blocks).
[  994.643231] st 6:0:3:0: [st1] Updating partition number in status.
[  994.643681] st 6:0:3:0: [st1] Got tape pos. blk 0 part 0.
[  994.643699] st 6:0:3:0: [st1] Loading tape.
[  994.644655] st 6:0:3:0: [st1] Block limits 1 - 16777215 bytes.
[  994.644972] st 6:0:3:0: [st1] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[  994.644976] st 6:0:3:0: [st1] Density 47, tape length: 0, drv buffer: 1
[  994.644980] st 6:0:3:0: [st1] Block size: 0, buffer size: 4096 (1 blocks).
[  994.645346] st 6:0:3:0: [st1] Partition page length is 10 bytes.
[  994.645352] st 6:0:3:0: [st1] PP: max 1, add 1, xdp 0, psum 02, pofmetc 0, 
rec 03, units 00, sizes: 1000 65535
[  994.645356] st 6:0:3:0: [st1] MP: 11 08 01 01 10 03 00 00 03 e8 ff ff
[  994.645359] st 6:0:3:0: [st1] psd_cnt 1, max.parts 1, nbr_parts 1
[  994.645362] st 6:0:3:0: [st1] Formatting tape with two partitions (1 = 1000 
MB).
[  994.645366] st 6:0:3:0: [st1] Sent partition page length is 10 bytes. 
needs_format: 0
[  994.645370] st 6:0:3:0: [st1] PP: max 1, add 1, xdp 1, psum 02, pofmetc 0, 
rec 03, units 00, sizes: 1000 65535
[  994.645374] st 6:0:3:0: [st1] MP: 11 08 01 01 30 03 00 00 03 e8 ff ff
[ 1372.970312] st 6:0:3:0: [st1] Rewinding tape.

# ./mt -f /dev/st1 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x47 (DDS-5 or TR-5).
Soft error count since last status=0
General status bits on (4101):
 BOT ONLINE IM_REP_EN
# ./mt -f /dev/st1 setpartition 1
# ./mt -f /dev/st1 status
SCSI 2 tape drive:
File number=0, block number=0, partition=1.
Tape block size 0 bytes. Density code 0x47 (DDS-5 or TR-5).
Soft error count since last status=0
General status bits on (4101):
 BOT ONLINE IM_REP_EN

And since you can only set the size of partition 1 on those drives as expected 
using a negative size fails:

# ./mt -f /dev/st1 mkpartition -500
/dev/st1: Invalid argument

[ 3937.384419] st 6:0:3:0: [st1] Block limits 1 - 16777215 bytes.
[ 3937.384710] st 6:0:3:0: [st1] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 3937.384715] st 6:0:3:0: [st1] Density 47, tape length: 0, drv buffer: 1
[ 3937.384718] st 6:0:3:0: [st1] Block size: 0, buffer size: 4096 (1 blocks).
[ 3937.384736] st 6:0:3:0: [st1] Loading tape.
[ 3937.385682] st 6:0:3:0: [st1] Block limits 1 - 16777215 bytes.
[ 3937.385983] st 6:0:3:0: [st1] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 3937.385988] st 6:0:3:0: [st1] Density 47, tape length: 0, drv buffer: 1
[ 3937.385991] st 6:0:3:0: [st1] Block size: 0, buffer size: 4096 (1 blocks).
[ 3937.386443] st 6:0:3:0: [st1] Partition page length is 10 bytes.
[ 3937.386450] st 6:0:3:0: [st1] PP: max 1, add 1, xdp 0, psum 02, pofmetc 0, 
rec 03, units 00, sizes: 1000 65535
[ 3937.386455] st 6:0:3:0: [st1] MP: 11 08 01 01 10 03 00 00 03 e8 ff ff
[ 3937.386577] st 6:0:3:0: [st1] Rewinding tape.

As expected LTO3 fails since it cannot be partitioned:

[ 4599.012299] st 5:0:1:0: [st0] Block limits 1 - 16777215 bytes.
[ 4599.014281] st 5:0:1:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 4599.014286] st 5:0:1:0: [st0] Density 44, tape length: 0, drv buffer: 1
[ 4599.014290] st 5:0:1:0: [st0] Block size: 0, buffer

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-28 Thread Kai Mäkisara (Kolumbus) 

> On 28.1.2016, at 9.36, Seymour, Shane M  wrote:
> 
> Hi Kai,
> 
> With the changes the I get a failure partitioning a HP DAT72 drive (DDS-5):
> 
> # ./mt -f /dev/st1 stsetoption debug
> # ./mt -f /dev/st1 stsetoption can-partitions
> # ./mt -f /dev/st1 mkpartition 1000
> /dev/st1: Input/output error
> 
...
> [ 3976.389605] st 6:0:3:0: [st1] Partition page length is 10 bytes.
> [ 3976.389610] st 6:0:3:0: [st1] PP: max 1, add 0, xdp 0, psum 02, pofmetc 0, 
> rec 03, units 00, sizes: 0 65535
> [ 3976.389614] st 6:0:3:0: [st1] MP: 11 08 01 00 10 03 00 00 00 00 ff ff
> [ 3976.389618] st 6:0:3:0: [st1] psd_cnt 2, max.parts 1, nbr_parts 0
 ^
The problem is here

...
> Using a slightly older kernel to partition the DAT72 drive works (same 3 
> commands as above):
...
> [  351.584906] st 6:0:3:0: [st1] Partition page length is 10 bytes.
> [  351.584908] st 6:0:3:0: [st1] psd_cnt 1, max.parts 1, nbr_parts 0

The old driver computes the psd_cnt from the returned page length. The same 
applies
to the patched driver if the SCSI level of the device < SCSI_3. This works 
correctly with
my drive that reports SCSI_2. So, the question is: what SCSI level does your 
device
report?

Kai

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

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-28 Thread Kai Mäkisara (Kolumbus) 

> On 27.1.2016, at 1.35, Seymour, Shane M  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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-28 Thread Laurence Oberman 
Hi Kai

What kernel was the last patch you attached against.

Thanks

Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

- Original Message -
From: "Kai Mäkisara (Kolumbus)" 
To: "Shane M Seymour" 
Cc: "Laurence Oberman" , "Emmanuel Florac" 
, "Laurence Oberman" , 
linux-scsi@vger.kernel.org
Sent: Thursday, January 28, 2016 12:04:20 PM
Subject: Re: What partition should the MTMKPART argument specify? Was: Re: st 
driver doesn't seem to grok LTO partitioning


> On 28.1.2016, at 9.36, Seymour, Shane M  wrote:
> 
> Hi Kai,
> 
> With the changes the I get a failure partitioning a HP DAT72 drive (DDS-5):
> 
> # ./mt -f /dev/st1 stsetoption debug
> # ./mt -f /dev/st1 stsetoption can-partitions
> # ./mt -f /dev/st1 mkpartition 1000
> /dev/st1: Input/output error
> 
...
> [ 3976.389605] st 6:0:3:0: [st1] Partition page length is 10 bytes.
> [ 3976.389610] st 6:0:3:0: [st1] PP: max 1, add 0, xdp 0, psum 02, pofmetc 0, 
> rec 03, units 00, sizes: 0 65535
> [ 3976.389614] st 6:0:3:0: [st1] MP: 11 08 01 00 10 03 00 00 00 00 ff ff
> [ 3976.389618] st 6:0:3:0: [st1] psd_cnt 2, max.parts 1, nbr_parts 0
 ^
The problem is here

...
> Using a slightly older kernel to partition the DAT72 drive works (same 3 
> commands as above):
...
> [  351.584906] st 6:0:3:0: [st1] Partition page length is 10 bytes.
> [  351.584908] st 6:0:3:0: [st1] psd_cnt 1, max.parts 1, nbr_parts 0

The old driver computes the psd_cnt from the returned page length. The same 
applies
to the patched driver if the SCSI level of the device < SCSI_3. This works 
correctly with
my drive that reports SCSI_2. So, the question is: what SCSI level does your 
device
report?

Kai

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

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-28 Thread Laurence Oberman 
Meant to mention, still waiting for my new LTO5, also this is the first time I 
am testing the DAT72.

Shane, have you had the DAT working before this last patch, if so which patch

Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

- Original Message -
From: "Laurence Oberman" 
To: "Shane M Seymour" 
Cc: "Kai Mäkisara (Kolumbus)" , "Emmanuel Florac" 
, "Laurence Oberman" , 
linux-scsi@vger.kernel.org
Sent: Thursday, January 28, 2016 6:23:13 PM
Subject: Re: What partition should the MTMKPART argument specify? Was: Re: st 
driver doesn't seem to grok LTO partitioning

On My DAT tape with the latest patch


[root@srp-server ~]# cat /sys/class/scsi_tape/st0/device/scsi_level
4

[root@srp-server ~]# mt -f /dev/st0 stsetoption can-partitions

Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 
bytes.
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 
0, drv buffer: 1
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer 
size: 4096 (1 blocks).
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Mode 0 options: buffer 
writes: 1, async writes: 1, read ahead: 1
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] can bsr: 1, two FMs: 
0, fast mteom: 0, auto lock: 0,
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] defs for wr: 0, no 
block limits: 0, partitions: 1, s2 log: 0
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] sysv: 0 nowait: 0 
sili: 0 nowait_filemark: 0
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] debugging: 1
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Rewinding tape.

[root@srp-server ~]# mt -f /dev/st0 mkpartition 1000

Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 
bytes.
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 
0, drv buffer: 1
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer 
size: 4096 (1 blocks).
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Loading tape.
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Error: 802, cmd: 0 0 0 
0 0 0
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Sense Key : Unit Attention 
[current]
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Add. Sense: Not ready to 
ready change, medium may have changed
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 
bytes.
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 
0, drv buffer: 1
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer 
size: 4096 (1 blocks).
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Partition page length is 
10 bytes.
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] PP: max 1, add 0, xdp 0, 
psum 02, pofmetc 0, rec 03, units 00, sizes: 0 65535
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] MP: 11 08 01 00 10 03 00 
00 00 00 ff ff
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] psd_cnt 2, max.parts 1, 
nbr_parts 0
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Formatting tape with two 
partitions (1 = 1000 MB).
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Sent partition page length 
is 12 bytes. needs_format: 0
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] PP: max 1, add 1, xdp 1, 
psum 02, pofmetc 0, rec 03, units 00, sizes: 65535 1000
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] MP: 11 0a 01 01 30 03 00 
00 ff ff 03 e8
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Error: 802, cmd: 15 10 
0 0 18 0
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Sense Key : Illegal 
Request [current]
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Add. Sense: Invalid field 
in parameter list
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Partitioning of tape 
failed.
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Rewinding tape.



Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

- Original Message -
From: "Shane M Seymour" 
To: "Kai Mäkisara (Kolumbus)" 
Cc: "Laurence Oberman" , "Emmanuel Florac" 
, "Laurence Oberman" , 
linux-scsi@vger.kernel.org
Sent: Thursday, January 28, 2016 6:12:41 PM
Subject: RE: What partition should the MTMKPART argument specify? Was: Re: st 
driver doesn't seem to grok LTO partitioning

Hi Kai,

$ pwd
/sys/class/scsi_tape/st1/device
$ cat scsi_level
4

Thanks
Shane

>

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-28 Thread Laurence Oberman 
On My DAT tape with the latest patch


[root@srp-server ~]# cat /sys/class/scsi_tape/st0/device/scsi_level
4

[root@srp-server ~]# mt -f /dev/st0 stsetoption can-partitions

Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 
bytes.
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 
0, drv buffer: 1
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer 
size: 4096 (1 blocks).
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Mode 0 options: buffer 
writes: 1, async writes: 1, read ahead: 1
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] can bsr: 1, two FMs: 
0, fast mteom: 0, auto lock: 0,
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] defs for wr: 0, no 
block limits: 0, partitions: 1, s2 log: 0
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] sysv: 0 nowait: 0 
sili: 0 nowait_filemark: 0
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] debugging: 1
Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Rewinding tape.

[root@srp-server ~]# mt -f /dev/st0 mkpartition 1000

Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 
bytes.
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 
0, drv buffer: 1
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer 
size: 4096 (1 blocks).
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Loading tape.
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Error: 802, cmd: 0 0 0 
0 0 0
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Sense Key : Unit Attention 
[current]
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Add. Sense: Not ready to 
ready change, medium may have changed
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 
bytes.
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 
0, drv buffer: 1
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer 
size: 4096 (1 blocks).
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Partition page length is 
10 bytes.
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] PP: max 1, add 0, xdp 0, 
psum 02, pofmetc 0, rec 03, units 00, sizes: 0 65535
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] MP: 11 08 01 00 10 03 00 
00 00 00 ff ff
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] psd_cnt 2, max.parts 1, 
nbr_parts 0
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Formatting tape with two 
partitions (1 = 1000 MB).
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Sent partition page length 
is 12 bytes. needs_format: 0
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] PP: max 1, add 1, xdp 1, 
psum 02, pofmetc 0, rec 03, units 00, sizes: 65535 1000
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] MP: 11 0a 01 01 30 03 00 
00 ff ff 03 e8
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Error: 802, cmd: 15 10 
0 0 18 0
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Sense Key : Illegal 
Request [current]
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Add. Sense: Invalid field 
in parameter list
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Partitioning of tape 
failed.
Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Rewinding tape.



Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

- Original Message -
From: "Shane M Seymour" 
To: "Kai Mäkisara (Kolumbus)" 
Cc: "Laurence Oberman" , "Emmanuel Florac" 
, "Laurence Oberman" , 
linux-scsi@vger.kernel.org
Sent: Thursday, January 28, 2016 6:12:41 PM
Subject: RE: What partition should the MTMKPART argument specify? Was: Re: st 
driver doesn't seem to grok LTO partitioning

Hi Kai,

$ pwd
/sys/class/scsi_tape/st1/device
$ cat scsi_level
4

Thanks
Shane

> -Original Message-
> From: "Kai Mäkisara (Kolumbus)" [mailto:kai.makis...@kolumbus.fi]
> Sent: Friday, January 29, 2016 4:04 AM
> To: Seymour, Shane M
> Cc: Laurence Oberman; Emmanuel Florac; Laurence Oberman; linux-
> s...@vger.kernel.org
> Subject: Re: What partition should the MTMKPART argument specify? Was:
> Re: st driver doesn't seem to grok LTO partitioning
> 
> 
> > On 28.1.2016, at 9.36, Seymour, Shane M 
> wrote:
> >
> > Hi Kai,
> >
> > With the changes the I get a failure partitioning a HP DAT72 drive (DDS-5):
> >
> > # ./mt -f /dev/st1 stsetoption debug
> > # ./mt -f /dev/st1 stsetoption can-partitions # ./mt -f /dev/st1
> > mkpartition 1000
> > /dev/st1: Input/output error
> >
> ...
> > [

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-28 Thread Seymour, Shane M 
Hi Kai,

$ pwd
/sys/class/scsi_tape/st1/device
$ cat scsi_level
4

Thanks
Shane

> -Original Message-
> From: "Kai Mäkisara (Kolumbus)" [mailto:kai.makis...@kolumbus.fi]
> Sent: Friday, January 29, 2016 4:04 AM
> To: Seymour, Shane M
> Cc: Laurence Oberman; Emmanuel Florac; Laurence Oberman; linux-
> s...@vger.kernel.org
> Subject: Re: What partition should the MTMKPART argument specify? Was:
> Re: st driver doesn't seem to grok LTO partitioning
> 
> 
> > On 28.1.2016, at 9.36, Seymour, Shane M 
> wrote:
> >
> > Hi Kai,
> >
> > With the changes the I get a failure partitioning a HP DAT72 drive (DDS-5):
> >
> > # ./mt -f /dev/st1 stsetoption debug
> > # ./mt -f /dev/st1 stsetoption can-partitions # ./mt -f /dev/st1
> > mkpartition 1000
> > /dev/st1: Input/output error
> >
> ...
> > [ 3976.389605] st 6:0:3:0: [st1] Partition page length is 10 bytes.
> > [ 3976.389610] st 6:0:3:0: [st1] PP: max 1, add 0, xdp 0, psum 02,
> > pofmetc 0, rec 03, units 00, sizes: 0 65535 [ 3976.389614] st 6:0:3:0:
> > [st1] MP: 11 08 01 00 10 03 00 00 00 00 ff ff [ 3976.389618] st
> > 6:0:3:0: [st1] psd_cnt 2, max.parts 1, nbr_parts 0
>  ^ The problem is 
> here
> 
> ...
> > Using a slightly older kernel to partition the DAT72 drive works (same 3
> commands as above):
> ...
> > [  351.584906] st 6:0:3:0: [st1] Partition page length is 10 bytes.
> > [  351.584908] st 6:0:3:0: [st1] psd_cnt 1, max.parts 1, nbr_parts 0
> 
> The old driver computes the psd_cnt from the returned page length. The
> same applies to the patched driver if the SCSI level of the device < SCSI_3.
> This works correctly with my drive that reports SCSI_2. So, the question is:
> what SCSI level does your device report?
> 
> Kai

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

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-28 Thread Kai Mäkisara (Kolumbus) 

> On 28.1.2016, at 21.21, Laurence Oberman  wrote:
> 
> Hi Kai
> 
> What kernel was the last patch you attached against.
> 
It was against the latest git version from Jan 24 evening (Finnish time). It is 
4.4.0 plus
from 4.5 merge window. The patch applies to 3.18.25 with offsets and should 
apply to
anything between these.

Kai

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

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-28 Thread Seymour, Shane M 
Hi Laurence,

> -Original Message-
> From: Laurence Oberman [mailto:lober...@redhat.com]
> Sent: Friday, January 29, 2016 10:25 AM
> To: Seymour, Shane M
> Cc: Kai Mäkisara (Kolumbus); Emmanuel Florac; Laurence Oberman; linux-
> s...@vger.kernel.org
> Subject: Re: What partition should the MTMKPART argument specify? Was:
> Re: st driver doesn't seem to grok LTO partitioning
> 
> Meant to mention, still waiting for my new LTO5, also this is the first time I
> am testing the DAT72.
> 
> Shane, have you had the DAT working before this last patch, if so which patch

The latest test was the first chance that I've had to test the changes. I 
didn't test the previous patches because I didn't have a partitionable LTO 
drive but I wanted to test the changes to set an explicit size for partition 0 
and 1 (since it's the only partitionable drive I have) and found it didn't work 
with the DAT72.

With a fedora user space (an old FC20 install) and a modified mt-st (to remove 
the negative test) compiled up I tested 4.4.0-next-20160113 (that also has some 
PCI patches in it for testing) with Kai's patch and it failed and I had an 
older kernel around (4.4.0-rc5-next-20151215) that I tested after seeing the 
failure and that works.

Thanks
Shane

> 
> Laurence Oberman
> Principal Software Maintenance Engineer
> Red Hat Global Support Services
> 
> - Original Message -
> From: "Laurence Oberman" 
> To: "Shane M Seymour" 
> Cc: "Kai Mäkisara (Kolumbus)" , "Emmanuel
> Florac" , "Laurence Oberman"
> , linux-scsi@vger.kernel.org
> Sent: Thursday, January 28, 2016 6:23:13 PM
> Subject: Re: What partition should the MTMKPART argument specify? Was:
> Re: st driver doesn't seem to grok LTO partitioning
> 
> On My DAT tape with the latest patch
> 
> 
> [root@srp-server ~]# cat /sys/class/scsi_tape/st0/device/scsi_level
> 4
> 
> [root@srp-server ~]# mt -f /dev/st0 stsetoption can-partitions
> 
> Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215
> bytes.
> Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11,
> medium 0, WBS 10, BLL 8 Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0]
> Density 47, tape length: 0, drv buffer: 1 Jan 28 18:17:49 srp-server kernel: 
> st
> 6:0:1:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
> Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Mode 0 options: buffer
> writes: 1, async writes: 1, read ahead: 1
> Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] can bsr: 1, two FMs: 
> 0, fast
> mteom: 0, auto lock: 0,
> Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] defs for wr: 0, no 
> block
> limits: 0, partitions: 1, s2 log: 0
> Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] sysv: 0 nowait: 0 
> sili: 0
> nowait_filemark: 0
> Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] debugging: 1
> Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Rewinding tape.
> 
> [root@srp-server ~]# mt -f /dev/st0 mkpartition 1000
> 
> Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215
> bytes.
> Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11,
> medium 0, WBS 10, BLL 8 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0]
> Density 47, tape length: 0, drv buffer: 1 Jan 28 18:18:01 srp-server kernel: 
> st
> 6:0:1:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
> Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Loading tape.
> Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Error: 802, cmd: 0 0 
> 0 0 0
> 0 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Sense Key : Unit 
> Attention
> [current] Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Add. Sense: Not
> ready to ready change, medium may have changed Jan 28 18:18:01 srp-server
> kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 bytes.
> Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11,
> medium 0, WBS 10, BLL 8 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0]
> Density 47, tape length: 0, drv buffer: 1 Jan 28 18:18:01 srp-server kernel: 
> st
> 6:0:1:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
> Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Partition page length is 
> 10
> bytes.
> Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] PP: max 1, add 0, xdp 0,
> psum 02, pofmetc 0, rec 03, units 00, sizes: 0 65535 Jan 28 18:18:01 
> srp-server
> kernel: st 6:0:1:0: [st0] MP: 11 08 01 00 10 03 00 00 00 00 ff ff Jan 28 
> 18:18:01
> srp-server kernel: st 6:0:1:0: [st0] psd_cnt 2, max.parts 1, nbr_parts 0 Jan 
> 28
> 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Formatting tape with two
> partitions (1 = 1000 MB).
> Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Sent partition page 
> length is
> 12 bytes. needs_format: 0 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0]
> PP: max 1, add 1, xdp 1, psum

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-28 Thread Emmanuel Florac 
Le Thu, 28 Jan 2016 19:31:10 +0200
"Kai Mäkisara (Kolumbus)"  écrivait:

> > On 27.1.2016, at 1.35, Seymour, Shane M 
> > 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 |   Direction technique
|   Intellique
|   
|   +33 1 78 94 84 02

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

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-27 Thread Seymour, Shane M 
Hi Kai,

With the changes the I get a failure partitioning a HP DAT72 drive (DDS-5):

# ./mt -f /dev/st1 stsetoption debug
# ./mt -f /dev/st1 stsetoption can-partitions
# ./mt -f /dev/st1 mkpartition 1000
/dev/st1: Input/output error

[ 3944.387190] st: Unloaded.
[ 3949.420128] st: Version 20160124, fixed bufsize 32768, s/g segs 256
[ 3949.421167] st 5:0:1:0: Attached scsi tape st0
[ 3949.421169] st 5:0:1:0: st0: try direct i/o: yes (alignment 512 B)
[ 3949.422108] st 6:0:3:0: Attached scsi tape st1
[ 3949.422112] st 6:0:3:0: st1: try direct i/o: yes (alignment 512 B)
[ 3955.866684] st 6:0:3:0: [st1] Block limits 1 - 16777215 bytes.
[ 3955.866992] st 6:0:3:0: [st1] Mode 0 options: buffer writes: 1, async 
writes: 1, read ahead: 1
[ 3955.866996] st 6:0:3:0: [st1] can bsr: 1, two FMs: 0, fast mteom: 0, 
auto lock: 0,
[ 3955.866999] st 6:0:3:0: [st1] defs for wr: 0, no block limits: 0, 
partitions: 0, s2 log: 0
[ 3955.867002] st 6:0:3:0: [st1] sysv: 0 nowait: 0 sili: 0 nowait_filemark:0
[ 3955.867005] st 6:0:3:0: [st1] debugging: 1
[ 3955.867010] st 6:0:3:0: [st1] Rewinding tape.
[ 3961.330913] st 6:0:3:0: [st1] Block limits 1 - 16777215 bytes.
[ 3961.331366] st 6:0:3:0: [st1] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 3961.331370] st 6:0:3:0: [st1] Density 47, tape length: 0, drv buffer: 1
[ 3961.331372] st 6:0:3:0: [st1] Block size: 0, buffer size: 4096 (1 blocks).
[ 3961.331384] st 6:0:3:0: [st1] Mode 0 options: buffer writes: 1, async 
writes: 1, read ahead: 1
[ 3961.331386] st 6:0:3:0: [st1] can bsr: 1, two FMs: 0, fast mteom: 0, 
auto lock: 0,
[ 3961.331388] st 6:0:3:0: [st1] defs for wr: 0, no block limits: 0, 
partitions: 1, s2 log: 0
[ 3961.331389] st 6:0:3:0: [st1] sysv: 0 nowait: 0 sili: 0 nowait_filemark: 0
[ 3961.331391] st 6:0:3:0: [st1] debugging: 1
[ 3961.331393] st 6:0:3:0: [st1] Rewinding tape.
[ 3976.387354] st 6:0:3:0: [st1] Block limits 1 - 16777215 bytes.
[ 3976.387651] st 6:0:3:0: [st1] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 3976.387653] st 6:0:3:0: [st1] Density 47, tape length: 0, drv buffer: 1
[ 3976.387655] st 6:0:3:0: [st1] Block size: 0, buffer size: 4096 (1 blocks).
[ 3976.387656] st 6:0:3:0: [st1] Updating partition number in status.
[ 3976.388001] st 6:0:3:0: [st1] Got tape pos. blk 0 part 0.
[ 3976.388013] st 6:0:3:0: [st1] Loading tape.
[ 3976.388909] st 6:0:3:0: [st1] Block limits 1 - 16777215 bytes.
[ 3976.389261] st 6:0:3:0: [st1] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 3976.389265] st 6:0:3:0: [st1] Density 47, tape length: 0, drv buffer: 1
[ 3976.389269] st 6:0:3:0: [st1] Block size: 0, buffer size: 4096 (1 blocks).
[ 3976.389605] st 6:0:3:0: [st1] Partition page length is 10 bytes.
[ 3976.389610] st 6:0:3:0: [st1] PP: max 1, add 0, xdp 0, psum 02, pofmetc 0, 
rec 03, units 00, sizes: 0 65535
[ 3976.389614] st 6:0:3:0: [st1] MP: 11 08 01 00 10 03 00 00 00 00 ff ff
[ 3976.389618] st 6:0:3:0: [st1] psd_cnt 2, max.parts 1, nbr_parts 0
[ 3976.389620] st 6:0:3:0: [st1] Formatting tape with two partitions (1 = 1000 
MB).
[ 3976.389623] st 6:0:3:0: [st1] Sent partition page length is 12 bytes. 
needs_format: 0
[ 3976.389627] st 6:0:3:0: [st1] PP: max 1, add 1, xdp 1, psum 02, pofmetc 0, 
rec 03, units 00, sizes: 65535 1000
[ 3976.389631] st 6:0:3:0: [st1] MP: 11 0a 01 01 30 03 00 00 ff ff 03 e8
[ 3976.390727] st 6:0:3:0: [st1] Error: 802, cmd: 15 10 0 0 18 0
[ 3976.390731] st 6:0:3:0: [st1] Sense Key : Illegal Request [current]
[ 3976.390734] st 6:0:3:0: [st1] Add. Sense: Invalid field in parameter list
[ 3976.390735] st 6:0:3:0: [st1] Partitioning of tape failed.
[ 3976.390806] st 6:0:3:0: [st1] Rewinding tape.

Using a slightly older kernel to partition the DAT72 drive works (same 3 
commands as above):

[  339.578950] st 6:0:3:0: [st1] Block limits 1 - 16777215 bytes.
[  339.579263] st 6:0:3:0: [st1] Mode 0 options: buffer writes: 1, async 
writes: 1, read ahead: 1
[  339.579266] st 6:0:3:0: [st1] can bsr: 1, two FMs: 0, fast mteom: 0, 
auto lock: 0,
[  339.579268] st 6:0:3:0: [st1] defs for wr: 0, no block limits: 0, 
partitions: 0, s2 log: 0
[  339.579269] st 6:0:3:0: [st1] sysv: 0 nowait: 0 sili: 0 nowait_filemark: 0
[  339.579271] st 6:0:3:0: [st1] debugging: 1
[  339.579275] st 6:0:3:0: [st1] Rewinding tape.
[  345.335252] st 6:0:3:0: [st1] Block limits 1 - 16777215 bytes.
[  345.335556] st 6:0:3:0: [st1] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[  345.335559] st 6:0:3:0: [st1] Density 47, tape length: 0, drv buffer: 1
[  345.335562] st 6:0:3:0: [st1] Block size: 0, buffer size: 4096 (1 blocks).
[  345.335573] st 6:0:3:0: [st1] Mode 0 options: buffer writes: 1, async 
writes: 1, read ahead: 1
[  345.335575] st 6:0:3:0: [st1] can bsr: 1, two FMs: 0, fast mteom: 0, 
auto lock: 0,
[  345.335577] st 6:0:3:0: [st1] defs for wr: 0, no block limits: 0, 
partitions: 1, s2 log: 0
[  345.335579] st 6:0:3:0: [st1] sysv: 0 nowait: 0 sili: 0 nowait_filemark: 0
[  345.335581] st 6:0:3:0:

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-26 Thread Seymour, Shane M 
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)

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-25 Thread Emmanuel Florac 
Le Sun, 24 Jan 2016 23:05:17 +0200 (EET)
Kai Makisara  écrivait:

> Below is a test patch that implements the current behaviour with 
> non-negative argument (but works with LTOs etc.) and makes partition 
> zero size absolute value of argument (MB) if argument is negative. If 
> you want to test the patch, note that the current mt-st does not
> accept negative numbers. A minimal patch is needed.

OK I'm going to try this one.

-- 

Emmanuel Florac |   Direction technique
|   Intellique
|   
|   +33 1 78 94 84 02

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

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-24 Thread Kai Makisara 
On Friday 2016-01-22 04:10, Seymour, Shane M wrote:


>> -Original Message-
>> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
>> ow...@vger.kernel.org] 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-
>> s...@vger.kernel.org
>> Subject: What partition should the MTMKPART argument specify? Was: Re:
>> st driver doesn't seem to grok LTO partitioning
>> 
...
>> 
>> 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.
>
I like this suggestion, because of the reasons you point out. I think 
this is using the fact that the argument is signed.

>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.
>
The value zero is used to specify only one partition. The previous 
patches overloaded the size 1. However, I think supporting FDP is 
useless nowadays: the drives that support FDP=1 seem to end up with the 
same partitioning (two wraps to partition 1) with any small number as 
argument.

Below is a test patch that implements the current behaviour with 
non-negative argument (but works with LTOs etc.) and makes partition 
zero size absolute value of argument (MB) if argument is negative. If 
you want to test the patch, note that the current mt-st does not accept 
negative numbers. A minimal patch is needed.

Thanks,
Kai
---8<
--- ref/drivers/scsi/st.c   2015-12-21 18:54:05.068882001 +0200
+++ new/drivers/scsi/st.c   2016-01-24 22:36:13.250928500 +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 kai.makis...@kolumbus.fi
 
Some small formal changes - aeb, 950809
@@ -17,7 +17,7 @@
Last modified: 18-JAN-1998 Richard Gooch  Devfs 
support
  */
 
-static const char *verstr = "20101219";
+static const char *verstr = "20160124";
 
 #include 
 
@@ -3296,7 +3296,10 @@
 #define PP_OFF_RESERVED7
 
 #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_POFM0x04
 
 /* 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,16 @@
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;
+   int target_partition;
+   bool scsi3 = STp->device->scsi_level >=

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-22 Thread Emmanuel Florac 

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

Le Fri, 22 Jan 2016 02:10:03 +
"Seymour, Shane M"  é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 :)


-- 

Emmanuel Florac |   Direction technique
|   Intellique
|   
|   +33 1 78 94 84 02

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

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-22 Thread Emmanuel Florac 
Le Fri, 22 Jan 2016 02:10:03 +
"Seymour, Shane M"  é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 |   Direction technique
|   Intellique
|   
|   +33 1 78 94 84 02

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

What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-21 Thread Kai Mäkisara (Kolumbus) 

> On 15.1.2016, at 2.21, Seymour, Shane M  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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-21 Thread Laurence Oberman 
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)" 
To: "Shane M Seymour" 
Cc: "Laurence Oberman" , "Emmanuel Florac" 
, "Laurence Oberman" , 
linux-scsi@vger.kernel.org
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  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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-21 Thread Seymour, Shane M 
Hi Kai,

> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] 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-
> s...@vger.kernel.org
> 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 
> 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 majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

2016-01-21 Thread Seymour, Shane M 
My applogies:

> 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.

I should have actually said:

You do get two wraps as a minimum in partition 1 and the rest minus two wraps
into partition 0. The extra two wraps are used as a guard between the two 
partitions
and all sizes will be rounded to a multiple of two wraps.

That was just to make it clear that partition sizes will always end up being a 
multiple
of 2x the wrap size and that there was some fixed overhead in partitioning an
LTO5+ drive (2 wraps).
N�r��yb�X��ǧv�^�)޺{.n�+{���"�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i