Re: st driver doesn't seem to grok LTO partitioning [coming back 2 and a half years later]

2018-07-18 Thread Emmanuel Florac
Le Fri, 15 Jan 2016 12:48:09 +0100
Emmanuel Florac  écrivait:

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

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

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

mt -f /dev/nst0 mkpartition 245

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


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

However with a slightly lower size it works:

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

With the log output:

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

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

Isn't life wonderful?

Cheers,
-- 

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



pgpSV1FSBsRE6.pgp
Description: Signature digitale OpenPGP


Re: st driver doesn't seem to grok LTO partitioning (LTO-5 firmware upgrade)

2017-12-25 Thread Jérôme Carretero
Hi,


This is just to state that I used the SAS LTO firmware upgrade method
Douglas suggested (1 year ago) and it worked fine, upgrading an HPE
LTO-5 Ultrium 3000 internal SAS tape drive from a .frm / .E file.


Best regards,

-- 
Jérôme

PS: It took me a while to find a way to get the latest firmware for
that drive, so here is some additional info: the Z6ED_019_233.E aka
LTT_Ultrium_5-SCSI_Z6ED_STANDALONE.frm firmware is available inside a
package not blocked by HPE paywall:
 
https://downloads.hpe.com/pub/softlib2/software1/sc-windows/p368283668/v124587/cp031432.exe
 
https://support.hpe.com/hpsc/swd/public/detail?sp4ts.oid=7271242&swItemId=MTX_afc26488547047b2b55cec874c&swEnvOid=4138#tab4


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
quot; , "Shane M Seymour" 

Cc: "Laurence Oberman" , "Emmanuel Florac" 
, "Laurence Oberman" , 
linux-scsi@vger.kernel.org
Sent: Thursday, February 4, 2016 1:09:30 PM
Subject: Re: What partition should the MTMKPART argument specify? Was: Re: st 
driver doesn't seem to grok LTO partitioning

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 fiel

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-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-03 Thread Seymour, Shane M
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.

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

[ 1871.160395] st 3:0:0:0: [st0] Block limits 1 - 16777215 bytes.
[ 1871.160955] st 3:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 1871.160958] st 3:0:0:0: [st0] Density 5a, tape length: 0, drv buffer: 1
[ 1871.160962] st 3:0:0:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
[ 1871.160963] st 3:0:0:0: [st0] Updating partition number in status.
[ 1871.161915] st 3:0:0:0: [st0] Got tape pos. blk 0 part 0.
[ 1871.161942] st 3:0:0:0: [st0] Loading tape.
[ 1871.176784] st 3:0:0:0: [st0] Block limits 1 - 16777215 bytes.
[ 1871.177284] st 3:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 1871.177289] st 3:0:0:0: [st0] Density 5a, tape length: 0, drv buffer: 1
[ 1871.177293] st 3:0:0:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
[ 1871.178632] st 3:0:0:0: [st0] Partition page length is 16 bytes.
[ 1871.178637] st 3:0:0:0: [st0] PP: max 3, add 1, xdp 1, psum 03, pofmetc 4, 
rec 03, units 09, sizes: 38 2543
[ 1871.178642] st 3:0:0:0: [st0] MP: 11 0e 03 01 3c 03 09 00 00 26 09 ef
[ 1871.178645] st 3:0:0:0: [st0] psd_cnt 2, max.parts 3, nbr_parts 1
[ 1871.178648] st 3:0:0:0: [st0] Formatting tape with two partitions (1 = 1 
MB).
[ 1871.178651] st 3:0:0:0: [st0] Sent partition page length is 12 bytes. 
needs_format: 1
[ 1871.178655] st 3:0:0:0: [st0] PP: max 3, add 1, xdp 1, psum 03, pofmetc 4, 
rec 03, units 09, sizes: 65535 10
[ 1871.178659] st 3:0:0:0: [st0] MP: 11 0a 03 01 3c 03 09 00 ff ff 00 0a
[ 1871.179655] st 3:0:0:0: [st0] Sending FORMAT MEDIUM
[ 1883.702742] st 3:0:0:0: [st0] Rewinding tape.

And we can change to partition 1 and back again. I ran this (I used the tell 
option but that failed more on that below):

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

Then wrote a tar archive to the drive and changed back to partition 0 and 
confirmed that I couldn't read the archive.

#  ./mt -f /dev/st0 mkpartition -1

[ 3813.227898] st 3:0:0:0: [st0] Block limits 1 - 16777215 bytes.
[ 3813.228399] st 3:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 3813.228404] st 3:0:0:0: [st0] Density 5a, tape length: 0, drv buffer: 1
[ 3813.228408] st 3:0:0:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
[ 3813.228427] st 3:0:0:0: [st0] Loading tape.
[ 3813.242855] st 3:0:0:0: [st0] Block limits 1 - 16777215 bytes.
[ 3813.243304] st 3:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 3813.243310] st 3:0:0:0: [st0] Density 5a, tape length: 0, drv buffer: 1
[ 3813.243313] st 3:0:0:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
[ 3813.244552] st 3:0:0:0: [st0] Partition page length is 16 bytes.
[ 3813.244559] st 3:0:0:0: [st0] PP: max 3, add 1, xdp 1, psum 03, pofmetc 4, 
rec 03, units 09, sizes: 2543 38
[ 3813.244564] st 3:0:0:0: [st0] MP: 11 0e 03 01 3c 03 09 00 09 ef 00 26
[ 3813.244567] st 3:0:0:0: [st0] psd_cnt 2, max.parts 3, nbr_parts 1
[ 3813.244570] st 3:0:0:0: [st0] Formatting tape with two partitions (0 = 1 
MB).
[ 3813.244573] st 3:0:0:0: [st0] Sent partition page length is 12 bytes. 
needs_format: 1
[ 3813.244578] st 3:0:0:0: [st0] PP: max 3, add 1, xdp 1, psum 03, pofmetc 4, 
rec 03, units 09, sizes: 10 65535
[ 3813.244582] st 3:0:0:0: [st0] MP: 11 0a 03 01 3c 03 09 00 00 0a ff ff
[ 3813.245907] st 3:0:0:0: [st0] Sending FORMAT MEDIUM
[ 3821.916760] st 3:0:0:0: [st0] Rewinding tape.

That worked and I did the same tar test after changing partitions to make sure 
that I couldn't read it back after changing back to partition 0.

I retested the DDS5 drive it still works as expected.

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(struc

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

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

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 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 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 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
 size: 4096 (1 blocks).
[ 4599.014356] st 5:0:1:0: [st0] Rewinding tape.
[ 4631.811295] st 5:0:1:0: [st0] Block limits 1 - 16777215 bytes.
[ 4631.813313] st 5:0:1:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 4631.813318] st 5:0:1:0: [st0] Density 44, tape length: 0, drv buffer: 1
[ 4631.813321] st 5:0:1:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
[ 4631.813342] st 5:0:1:0: [st0] Mode 0 options: buffer writes: 1, async 
writes: 1, read ahead: 1
[ 4631.813345] st 5:0:1:0: [st0] can bsr: 1, two FMs: 0, fast mteom: 0, 
auto lock: 0,
[ 4631.813348] st 5:0:1:0: [st0] defs for wr: 0, no block limits: 0, 
partitions: 1, s2 log: 0
[ 4631.813351] st 5:0:1:0: [st0] sysv: 0 nowait: 0 sili: 0 nowait_filemark: 0
[ 4631.813354] st 5:0:1:0: [st0] debugging: 1
[ 4631.813359] st 5:0:1:0: [st0] Rewinding tape.
[ 4648.170712] st 5:0:1:0: [st0] Block limits 1 - 16777215 bytes.
[ 4648.172774] st 5:0:1:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 4648.172779] st 5:0:1:0: [st0] Density 44, tape length: 0, drv buffer: 1
[ 4648.172783] st 5:0:1:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
[ 4648.172786] st 5:0:1:0: [st0] Updating partition number in status.
[ 4648.175584] st 5:0:1:0: [st0] Got tape pos. blk 0 part 0.
[ 4648.175604] st 5:0:1:0: [st0] Loading tape.
[ 4648.209689] st 5:0:1:0: [st0] Block limits 1 - 16777215 bytes.
[ 4648.212799] st 5:0:1:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 4648.212804] st 5:0:1:0: [st0] Density 44, tape length: 0, drv buffer: 1
[ 4648.212808] st 5:0:1:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
[ 4648.215855] st 5:0:1:0: [st0] Partition page length is 10 bytes.
[ 4648.215861] st 5:0:1:0: [st0] PP: max 0, add 0, xdp 0, psum 03, pofmetc 0, 
rec 03, units 09, sizes: 400 65535
[ 4648.215866] st 5:0:1:0: [st0] MP: 11 08 00 00 18 03 09 00 01 90 ff ff
[ 4648.215869] st 5:0:1:0: [st0] psd_cnt 1, max.parts 0, nbr_parts 0
[ 4648.215872] st 5:0:1:0: [st0] Formatting tape with two partitions (1 = 1000 
MB).
[ 4648.215875] st 5:0:1:0: [st0] Sent partition page length is 10 bytes. 
needs_format: 0
[ 4648.215879] st 5:0:1:0: [st0] PP: max 0, add 1, xdp 1, psum 03, pofmetc 0, 
rec 03, units 09, sizes: 65535 1
[ 4648.215883] st 5:0:1:0: [st0] MP: 11 08 00 01 38 03 09 00 ff ff 00 01
[ 4648.220140] st 5:0:1:0: [st0] Error: 802, cmd: 15 10 0 0 16 0
[ 4648.220145] st 5:0:1:0: [st0] Sense Key : Illegal Request [current]
[ 4648.220149] st 5:0:1:0: [st0] Add. Sense: Invalid field in parameter list
[ 4648.220153] st 5:0:1:0: [st0] Partitioning of tape failed.
[ 4648.220269] st 5:0:1:0: [st0] Rewinding tape.

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.

Thanks
Shane

> -Original Message-
> From: makisara@kai.makisara.private [mailto:makisara@kai.makisara.private]
> On Behalf Of Kai Makisara
> Sent: Saturday, January 30, 2016 4:22 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 Friday 2016-01-29 01:12, Seymour, Shane M wrote:
> 
> >Date: Fri, 29 Jan 2016 01:12:41
> >From: "Seymour, Shane M" 
> >To: "\"Kai Mäkisara (Kolumbus)\"" 
> >Cc: Laurence Oberman ,
> >Emmanuel Florac ,
> >Laurence Oberman ,
> >"linux-scsi@vger.kernel.org" 
> >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
> >
> OK. The previous patch set the number of partition size descriptors to
> one for HP DATs only if the SCSI level was <= SCSI_2.
> 
&g

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

2016-01-29 Thread Kai Makisara
On Friday 2016-01-29 01:12, Seymour, Shane M wrote:

>Date: Fri, 29 Jan 2016 01:12:41
>From: "Seymour, Shane M" 
>To: "\"Kai Mäkisara (Kolumbus)\"" 
>Cc: Laurence Oberman ,
>Emmanuel Florac ,
>Laurence Oberman ,
>"linux-scsi@vger.kernel.org" 
>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
>
OK. The previous patch set the number of partition size descriptors to 
one for HP DATs only if the SCSI level was <= SCSI_2.

The patch below uses that logic for all drives that don't need FORMAT 
MEDIUM. For the drives needing FORMAT MEDIUM the value is set to 2. 
These drives include LTOs and other modern drives.

Thanks, Kai
-8<--
--- ref/drivers/scsi/st.c   2015-12-21 18:54:05.068882001 +0200
+++ new/drivers/scsi/st.c   2016-01-29 19:12:06.139738037 +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 = "20160129";
 
 #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 >= SCSI_3, needs_format = false;
int pgo, psd_cnt, psdo;
+   int psum = PP_MSK_PSUM_MB, units = 0;
unsigned char *bp;
 
result = read_mode_page(STp, PART_PAGE, 0);
@@ -3352,16 +3383,72 @@
DEBC_printk(STp, "Can't read partition mode page.\n");
return result;
}
+   target_partition = 1;
+   if (size < 0) {
+   target_partition = 0;
+   size = -size;
+   }
+
/* The mode page is in the buffer. Let's modify it and write it. */
bp = (STp->buffer)->b_data;
pgo = MODE_HEADER_LENGTH + bp[MH_OFF_BDESCS_LENGTH];
DEBC_printk(STp, "Partition page length is %d bytes.\n",
bp[pgo + MP_OFF_PAGE_LENGTH] + 2);
+   DEBC_printk(STp, "PP: max %u, add %u, xdp %u, psum %02x, pofmetc %u, "
+   "rec %02x, units %02x, sizes: %u %u\n",
+   bp[pgo + PP_OFF_MAX_ADD_PARTS],
+   bp[pgo + PP_OFF_NBR_ADD_PARTS],
+   (bp[pgo + PP_OFF_FLAGS] & 0xe0) >> 5,
+   (bp[pgo + PP_OFF_FLAGS] & 0x18) >> 3,
+   bp[pgo + PP_OFF_FLAGS] & 0x07,
+   bp[pgo + 5],
+   bp[pgo + PP_OFF_PART_UNITS],
+   bp[pgo + 8] * 256 + bp[pgo + 9],
+   bp[pgo + 10] * 256 + bp[pgo + 11]);
+   DEBC_printk(STp, "MP: %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x 
%02x %02x\n",
+   bp[pgo], bp[pgo+1], bp[p

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] Formattin

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

> -Original Message-
> From: "Kai Mäkisara (Kolumbus)" [mailto:kai.makis...@kolumbus.fi]
> Se

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/o

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 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 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-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 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-27 Thread Seymour, Shane M
: [st1] debugging: 1
[  345.335583] st 6:0:3:0: [st1] Rewinding tape.
[  351.583495] st 6:0:3:0: [st1] Block limits 1 - 16777215 bytes.
[  351.583779] st 6:0:3:0: [st1] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[  351.583782] st 6:0:3:0: [st1] Density 47, tape length: 0, drv buffer: 1
[  351.583783] st 6:0:3:0: [st1] Block size: 0, buffer size: 4096 (1 blocks).
[  351.583785] st 6:0:3:0: [st1] Updating partition number in status.
[  351.584184] st 6:0:3:0: [st1] Got tape pos. blk 0 part 0.
[  351.584196] st 6:0:3:0: [st1] Rewinding tape.
[  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
[  351.584910] st 6:0:3:0: [st1] Formatting tape with two partitions (1 = 1000 
MB).
[  723.976554] st 6:0:3:0: [st1] Rewinding tape.

Thanks
Shane

> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Kai Makisara
> Sent: Monday, January 25, 2016 8:05 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 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-19

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 addition

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


Re: st driver doesn't seem to grok LTO partitioning

2016-01-22 Thread Douglas Gilbert

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

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

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

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

Doug Gilbert


On 16-01-14 09:12 PM, Laurence Oberman wrote:

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

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

The image I have is the correct image.

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

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

Thanks

Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

- Original Message -
From: "Emmanuel Florac" 
To: "Laurence Oberman" 
Cc: "Laurence Oberman" , "Kai Makisara" 
, linux-scsi@vger.kernel.org
Sent: Wednesday, January 6, 2016 11:07:20 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning

Le Wed, 6 Jan 2016 10:23:34 -0500 (EST)
Laurence Oberman  écrivait:


MaxPartitions: 0

Drive is working fine,

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

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


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



--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to 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

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


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: st driver doesn't seem to grok LTO partitioning

2016-01-06 Thread Emmanuel Florac
Le Mon, 4 Jan 2016 12:22:34 +0200 (EET)
Kai Makisara  écrivait:

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

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

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


-- 

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: st driver doesn't seem to grok LTO partitioning

2016-01-06 Thread Emmanuel Florac
Le Wed, 6 Jan 2016 17:10:15 +0100
Emmanuel Florac  écrivait:

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

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

-- 

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: st driver doesn't seem to grok LTO partitioning

2016-01-06 Thread Emmanuel Florac
Le Mon, 4 Jan 2016 12:46:26 +0100
Emmanuel Florac  écrivait:

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

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

# mt -f /dev/st0 mkpartition 1


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


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

# mt -f /dev/st0 setpartition 1

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

# mt -f /dev/st0 mkpartition 1453

Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, 
WBS 10, BLL 8
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv 
buffer: 1
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 
(1 blocks).
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Loading tape.
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes.
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, 
WBS 10, BLL 8
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv 
buffer: 1
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 
(1 blocks).
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Partition page length is 12 
bytes.
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: PP: max 1, add 1, xdp 1, psum 
03, pofmetc 4, rec 03, units 09, sizes: 1453 38
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: MP: 11 0a 01 01 3c 03 09 00 05 
ad 00 26
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: psd_cnt 2, max.parts 1, 
nbr_parts 1
Jan  6 16:42:22 taiko kernel: st 6:0:0:0: st0: Formatting tape with two 
partitions (1 = 1

Re: st driver doesn't seem to grok LTO partitioning

2016-01-06 Thread Emmanuel Florac
Le Wed, 6 Jan 2016 10:23:34 -0500 (EST)
Laurence Oberman  écrivait:

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

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

-- 

Emmanuel Florac |   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: st driver doesn't seem to grok LTO partitioning

2016-01-06 Thread Laurence Oberman
Thanks Doug
Trying that now


Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

- Original Message -
From: "Douglas Gilbert" 
To: "Laurence Oberman" , "Emmanuel Florac" 

Cc: "Laurence Oberman" , "Kai Makisara" 
, linux-scsi@vger.kernel.org
Sent: Wednesday, January 6, 2016 10:48:44 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning

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

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

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

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

Doug Gilbert

> - Original Message -
> From: "Laurence Oberman" 
> To: "Emmanuel Florac" 
> Cc: "Laurence Oberman" , "Kai Makisara" 
> , linux-scsi@vger.kernel.org
> Sent: Wednesday, January 6, 2016 10:25:37 AM
> Subject: Re: st driver doesn't seem to grok LTO partitioning
>
> I left the log of the failure to partition out
>
> Here it is
>
> # mt -f /dev/nst0  mkpartition 1
> /dev/nst0: Input/output error
>
> [ 5499.341648] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
> [ 5499.342903] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 
> 8
> [ 5499.343523] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
> [ 5499.344114] st 0:0:0:0: [st0] Block size: 512, buffer size: 4096 (8 
> blocks).
> [ 5499.344702] st 0:0:0:0: [st0] Loading tape.
> [ 5499.359733] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
> [ 5499.360970] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 
> 8
> [ 5499.361584] st 0:0:0:0: [st0] Density 58, tape length: 0, drv buffer: 1
> [ 5499.362165] st 0:0:0:0: [st0] Block size: 512, buffer size: 4096 (8 
> blocks).
> [ 5499.363851] st 0:0:0:0: [st0] Partition page length is 10 bytes.
> [ 5499.364468] st 0:0:0:0: [st0] PP: max 0, add 0, xdp 0, psum 03, pofmetc 
> 0,rec 03, units 09, sizes: 1541 65535
> [ 5499.365074] st 0:0:0:0: [st0] MP: 11 08 00 00 18 03 09 00 06 05 ff ff
> [ 5499.365658] st 0:0:0:0: [st0] psd_cnt 2, max.parts 0, nbr_parts 0
> [ 5499.366246] st 0:0:0:0: [st0] Formatting tape with two partitions (FDP).
> [ 5499.366826] st 0:0:0:0: [st0] Sent partition page length is 12 bytes.  
> needs_format: 0
> [ 5499.367424] st 0:0:0:0: [st0] PP: max 0, add 1, xdp 4, psum 03, pofmetc 0 
> rec 03, units 00, sizes: 65535 65535
> [ 5499.368024] st 0:0:0:0: [st0] MP: 11 0a 00 01 98 03 00 00 ff ff ff ff
> [ 5499.369842] st 0:0:0:0: [st0] Error: 802, cmd: 15 10 0 0 18 0
> [ 5499.370495] st 0:0:0:0: [st0] Sense Key : Illegal Request [current]
> [ 5499.371109] st 0:0:0:0: [st0] Add. Sense: Invalid field in parameter list
> [ 5499.371714] st 0:0:0:0: [st0] Partitioning of tape failed.
>
> Laurence Oberman
> Principal Software Maintenance Engineer
> Red Hat Global Support Services
>
> - Original Message -
> From: "Laurence Oberman" 
> To: "Emmanuel Florac" 
> Cc: "Laurence Oberman" , "Kai Makisara" 
> , linux-scsi@vger.kernel.org
> Sent: Wednesday, January 6, 2016 10:23:34 AM
> Subject: Re: st driver doesn't seem to grok LTO partitioning
>
> Hello Emanuel
>
> I am using this device, its an Ultrium 5 (LTO5)
> Its an older changer and I am unable to update the firmware, still working on 
> that.
>
> What version of mt are you using, as I am testing using a RHEL7.2 base and 
> the upstream patched kernel.
>
> Linux e

Re: st driver doesn't seem to grok LTO partitioning

2016-01-06 Thread Douglas Gilbert

On 16-01-06 10:32 AM, Laurence Oberman wrote:

Firmware update fails as follows:

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

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

Performing FUP operation...

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

Checking device readiness

Sending image file to the device

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

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

Unable to perform FUP operation.


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

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

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

Doug Gilbert


- Original Message -
From: "Laurence Oberman" 
To: "Emmanuel Florac" 
Cc: "Laurence Oberman" , "Kai Makisara" 
, linux-scsi@vger.kernel.org
Sent: Wednesday, January 6, 2016 10:25:37 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning

I left the log of the failure to partition out

Here it is

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

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

Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

- Original Message -
From: "Laurence Oberman" 
To: "Emmanuel Florac" 
Cc: "Laurence Oberman" , "Kai Makisara" 
, linux-scsi@vger.kernel.org
Sent: Wednesday, January 6, 2016 10:23:34 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning

Hello Emanuel

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

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

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

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

Drive is working fine,

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

Re: st driver doesn't seem to grok LTO partitioning

2016-01-06 Thread Laurence Oberman
Firmware update fails as follows:

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

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

Performing FUP operation...

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

Checking device readiness

Sending image file to the device

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

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

Unable to perform FUP operation.


Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

- Original Message -
From: "Laurence Oberman" 
To: "Emmanuel Florac" 
Cc: "Laurence Oberman" , "Kai Makisara" 
, linux-scsi@vger.kernel.org
Sent: Wednesday, January 6, 2016 10:25:37 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning

I left the log of the failure to partition out

Here it is

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

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

Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

- Original Message -
From: "Laurence Oberman" 
To: "Emmanuel Florac" 
Cc: "Laurence Oberman" , "Kai Makisara" 
, linux-scsi@vger.kernel.org
Sent: Wednesday, January 6, 2016 10:23:34 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning

Hello Emanuel

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

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

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

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

Drive is working fine,

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

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

mt -f /dev/st0  stsetoption can-partitions

[ 5343.620005] st 0:0:0:0: [st0] Block limits 1 - 16777215 bytes.
[ 5343.621424] st 0:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 5343.622005] st 0:0:0:0: [st0] Density

Re: st driver doesn't seem to grok LTO partitioning

2016-01-06 Thread Laurence Oberman
I left the log of the failure to partition out

Here it is

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

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

Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

- Original Message -
From: "Laurence Oberman" 
To: "Emmanuel Florac" 
Cc: "Laurence Oberman" , "Kai Makisara" 
, linux-scsi@vger.kernel.org
Sent: Wednesday, January 6, 2016 10:23:34 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning

Hello Emanuel

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

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

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

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

Drive is working fine,

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

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

mt -f /dev/st0  stsetoption can-partitions

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

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





Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

- Original Message -
From: "Emmanuel Florac" 
To: "Laurence Oberman" 
Cc: "Laurence Oberman" , "Kai Makisara" 
, linux-scsi@vger.kernel.org
Sent: Wednesday, January 6, 2016 10:10:49 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning

Le Tue, 5 Jan 2016 16:55:04 -0500 (EST)
Laurence Oberman  écrivait:

> mt -f /dev/nst0  mkpartition 1
> 

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

Re: st driver doesn't seem to grok LTO partitioning

2016-01-06 Thread Laurence Oberman
Hello Emanuel

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

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

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

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

Drive is working fine,

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

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

mt -f /dev/st0  stsetoption can-partitions

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

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





Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

- Original Message -
From: "Emmanuel Florac" 
To: "Laurence Oberman" 
Cc: "Laurence Oberman" , "Kai Makisara" 
, linux-scsi@vger.kernel.org
Sent: Wednesday, January 6, 2016 10:10:49 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning

Le Tue, 5 Jan 2016 16:55:04 -0500 (EST)
Laurence Oberman  écrivait:

> mt -f /dev/nst0  mkpartition 1
> 

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

-- 

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: st driver doesn't seem to grok LTO partitioning

2016-01-06 Thread Emmanuel Florac
Le Tue, 5 Jan 2016 16:55:04 -0500 (EST)
Laurence Oberman  écrivait:

> mt -f /dev/nst0  mkpartition 1
> 

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

-- 

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: st driver doesn't seem to grok LTO partitioning

2016-01-05 Thread Laurence Oberman
Testing the patch here in the lab, it seems my firmware will need to be updated 
to support more than 1 partition.
Looking into that now.

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

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

 mt -f /dev/st0  stsetoption can-partitions

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

mt -f /dev/nst0  mkpartition 1

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



Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services


From: Emmanuel Florac 
Date: Mon, Jan 4, 2016 at 6:46 AM
Subject: Re: st driver doesn't seem to grok LTO partitioning
To: Kai Makisara 
Cc: linux-scsi@vger.kernel.org


Le Mon, 4 Jan 2016 12:22:34 +0200 (EET)
Kai Makisara  écrivait:

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

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

# modprobe st

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


# mt -f /dev/st0  stsetoption debug

Jan  4 12:32:04 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1

Re: st driver doesn't seem to grok LTO partitioning

2016-01-04 Thread Emmanuel Florac
Le Mon, 4 Jan 2016 10:08:44 -0500
Laurence Oberman  écrivait:

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

No only the latest one.

-- 

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: st driver doesn't seem to grok LTO partitioning

2016-01-04 Thread Emmanuel Florac
Le Mon, 4 Jan 2016 12:22:34 +0200 (EET)
Kai Makisara  écrivait:

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

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

# modprobe st

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


# mt -f /dev/st0  stsetoption debug

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

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


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

# mt -f /dev/nst0  mkpartition 1


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

Re: st driver doesn't seem to grok LTO partitioning

2016-01-04 Thread Emmanuel Florac
Le Mon, 4 Jan 2016 12:22:34 +0200 (EET)
Kai Makisara  écrivait:

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

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

First, not working:

# mt -f /dev/nst0 mkpartition 0

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

Then:

# mt -f /dev/nst0 load

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

# mt -f /dev/nst0 mkpartition 0


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

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


-- 

Emmanuel Florac |   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: st driver doesn't seem to grok LTO partitioning

2016-01-04 Thread Emmanuel Florac
Le Mon, 4 Jan 2016 12:22:34 +0200 (EET)
Kai Makisara  écrivait:

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

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

-- 

Emmanuel Florac |   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: st driver doesn't seem to grok LTO partitioning

2016-01-04 Thread Kai Makisara
On Thursday 2015-12-31 18:08, "Kai Mäkisara (Kolumbus)" wrote:

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

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

Kai
-8<
--- ref/drivers/scsi/st.c   2015-12-21 18:54:05.068882001 +0200
+++ new/drivers/scsi/st.c   2016-01-04 12:09:07.702559815 +0200
@@ -9,7 +9,7 @@
Steve Hirsch, Andreas Koppenh"ofer, Michael Leodolter, Eyal Lebedinsky,
Michael Schaefer, J"org Weule, and Eric Youngdale.
 
-   Copyright 1992 - 2010 Kai Makisara
+   Copyright 1992 - 2016 Kai Makisara
email 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 = "20160104";
 
 #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,15 @@
and 10 when 1 partition is defined (information from Eric Lee Green). This 
is
is acceptable also to some other old drives and enforced if the first 
partition
size field is used for the first additional partition size.
+
+   For drives that advertize SCSI-3 or newer, use the SSC-3 methods.
  */
 static int partition_tape(struct scsi_tape *STp, int size)
 {
int result;
+   bool scsi3 = STp->device->scsi_level >= SCSI_3,  needs_format = false;
int pgo, psd_cnt, psdo;
+   int psum = PP_MSK_PSUM_MB, units = 0;
unsigned char *bp;
 
result = read_mode_page(STp, PART_PAGE, 0);
@@ -3357,11 +3387,58 @@
pgo = MODE_HEADER_LENGTH + bp[MH_OFF_BDESCS_LENGTH];
DEBC_printk(STp, "Partition page length is %d bytes.\n",
bp[pgo + MP_OFF_PAGE_LENGTH] + 2);
+   DEBC_printk(STp, "PP: max %u, add %u, xdp %u, psum %02x, pofmetc %u, "
+   "rec %02x, units %02x, sizes: %u %u\n",
+   bp[pgo + PP_OFF_MAX_ADD_PARTS],
+   bp[pgo + PP_OFF_NBR_ADD_PARTS],
+   (bp[pgo + PP_OFF_FLAGS] & 0xe0) >> 5,
+   (bp[pgo + PP_OFF_FLAGS] & 0x18) >> 3,
+   bp[pgo + PP_OFF_FLAGS] & 0x07,
+   bp[pgo + 5],
+   bp[pgo + PP_OFF_PART_UNITS],
+   bp[pgo + 8] * 256 + bp[pgo + 9],
+   bp[pgo + 10] * 256 + bp[pgo + 11]);
+   DEBC_printk(STp, "MP: %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x 
%02x %02x\n",
+   bp[pgo], bp[pgo+1], bp[pgo+2], bp[pgo+3], bp[pgo+4], 
bp[pgo+5],
+   bp[pgo+6], bp[pgo+7], bp[pgo+8], bp[pgo+9], bp[pgo+10], 
bp[pgo+11]);
+
+   if (scsi3) {
+   needs_format = (bp[pgo + PP_OFF_FLAGS] & PP_MSK_POFM) != 0;
+   if (needs_format && size == 0) {
+   /* No need to write the mode page in this case */
+   result = format_medium(STp, 0);
+   goto out;
+   }
+
+   psd_cnt = size > 0 ? 2 : 1;
+   if ((bp[pgo + PP_OFF_FLAGS] & PP_MSK_PSUM_UNITS) == 
PP_MSK_PSUM_UNITS) {
+   /* Use units scaling for large partitions if the device 
suggests
+  it and no precision lost. Required for IBM TS1140/50 
drives
+  that don't support MB units. */
+

Re: st driver doesn't seem to grok LTO partitioning

2015-12-31 Thread Kai Mäkisara (Kolumbus)

> On 30.12.2015, at 23.24, Emmanuel Florac  wrote:
> 
> Le Wed, 30 Dec 2015 21:21:47 +0200
> "Kai Mäkisara (Kolumbus)"  écrivait:
> 
>> This happens if the position is not at the beginning of partition 0.
>> Could you try to switch to partition 0:
>> mt -f /dev/nst0 setpartition 0
>> mt -f /dev/nst0 status
>> 
>> and the retry partitioning.
> 
> Alas, no dice:
> 
OK.

In the HP LTFS sources I found an interesting detail: the code does LOAD before 
unformatting.
A comment says that it is in some cases better method to put the position to 
beginning of
partition 0 than other methods. You could try ‘mt load’ before trying to 
partition.

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: st driver doesn't seem to grok LTO partitioning

2015-12-30 Thread Emmanuel Florac
Le Wed, 30 Dec 2015 21:21:47 +0200
"Kai Mäkisara (Kolumbus)"  écrivait:

> This happens if the position is not at the beginning of partition 0.
> Could you try to switch to partition 0:
> mt -f /dev/nst0 setpartition 0
> mt -f /dev/nst0 status
> 
> and the retry partitioning.

Alas, no dice:

# mt -f /dev/nst0 setpartition 0


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

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

Dec 30 22:19:49 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 
bytes.
Dec 30 22:19:49 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Dec 30 22:19:49 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, 
drv buffer: 1
Dec 30 22:19:49 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 
4096 (1 blocks).

# mt -f /dev/nst0 mkpartition 0

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



-- 

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: st driver doesn't seem to grok LTO partitioning

2015-12-30 Thread Kai Mäkisara (Kolumbus)

> On 30.12.2015, at 20.33, Emmanuel Florac  wrote:
> 
> Le Wed, 30 Dec 2015 19:54:01 +0200 (EET)
> Kai Makisara  écrivait:
> 
>> I think I found out why it did not work with the default format. At
>> the end of this message you find a new patch that should correct
>> that. There are also other changes:
>> - some changes when specifying the size in the mode page; needed for
>> the IBM 3592 drives but should not change results with LTO
>> - formatting with one partition is done directly with FORMAT MEDIUM if
>>  the drive requires that command
>> - some other bugs fixed
> 
> Hum, I can't seem to be able to go back to 1 partition, or to reformat
> the tape (didn't change it since yesterday), am I missing something?
> 
> Dec 30 19:21:29 shakuhachi kernel: st: Version 20151230, fixed bufsize 32768, 
> s/g segs 256
> Dec 30 19:21:29 shakuhachi kernel: st 7:0:0:0: Attached scsi tape st0
> Dec 30 19:21:29 shakuhachi kernel: st 7:0:0:0: st0: try direct i/o: yes 
> (alignment 512 B)
> 
> ~# mt -f /dev/nst0  mkpartition 0
> 
> Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 
> bytes.
> Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, 
> medium 0, WBS 10, BLL 8
> Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 
> 0, drv buffer: 1
> Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer 
> size: 4096 (1 blocks).
> Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape.
> Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: Partition page length is 
> 16 bytes.
> Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 1, 
> psum 03, pofmetc 4, rec 03, units 09, sizes: 2543 38
> Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: Sending FORMAT MEDIUM
> Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: Error: 802, cmd: 4 0 
> 0 0 0 0
> Dec 30 19:24:41 shakuhachi kernel: st0: Sense Key : Illegal Request [current] 
> Dec 30 19:24:41 shakuhachi kernel: st0: Add. Sense: Position past beginning 
> of medium

This happens if the position is not at the beginning of partition 0. Could you 
try
to switch to partition 0:
mt -f /dev/nst0 setpartition 0
mt -f /dev/nst0 status

and the retry partitioning.

> ~# mt -f /dev/nst0  mkpartition 1
> 
> Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 
> bytes.
> Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, 
> medium 0, WBS 10, BLL 8
> Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 
> 0, drv buffer: 1
> Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer 
> size: 4096 (1 blocks).
> Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape.
> Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Partition page length is 
> 16 bytes.
> Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 1, 
> psum 03, pofmetc 4, rec 03, units 09, sizes: 2543 38
> Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: psd_cnt 2, max.parts 3, 
> nbr_parts 1
> Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Formatting tape with two 
> partitions (FDP).
> Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Sent partition page 
> length is 12 bytes. needs_format: 1
> Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 4, 
> psum 00, pofmetc 4, rec 03, units 00, sizes: 65535 0
> Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Error: 802, cmd: 15 
> 10 0 0 18 0
> Dec 30 19:26:12 shakuhachi kernel: st0: Sense Key : Illegal Request [current] 
> Dec 30 19:26:12 shakuhachi kernel: st0: Add. Sense: Invalid field in 
> parameter list
> Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Partitioning of tape 
> failed.
> 
I have to recheck what it set into the mode page. It is still not correct in 
this case.

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: st driver doesn't seem to grok LTO partitioning

2015-12-30 Thread Emmanuel Florac
Le Wed, 30 Dec 2015 19:54:01 +0200 (EET)
Kai Makisara  écrivait:

> I think I found out why it did not work with the default format. At
> the end of this message you find a new patch that should correct
> that. There are also other changes:
> - some changes when specifying the size in the mode page; needed for
> the IBM 3592 drives but should not change results with LTO
> - formatting with one partition is done directly with FORMAT MEDIUM if
>   the drive requires that command
> - some other bugs fixed

Hum, I can't seem to be able to go back to 1 partition, or to reformat
the tape (didn't change it since yesterday), am I missing something?

Dec 30 19:21:29 shakuhachi kernel: st: Version 20151230, fixed bufsize 32768, 
s/g segs 256
Dec 30 19:21:29 shakuhachi kernel: st 7:0:0:0: Attached scsi tape st0
Dec 30 19:21:29 shakuhachi kernel: st 7:0:0:0: st0: try direct i/o: yes 
(alignment 512 B)

~# mt -f /dev/nst0  mkpartition 0

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

~# mt -f /dev/nst0  mkpartition 1

Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 
bytes.
Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, 
drv buffer: 1
Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 
4096 (1 blocks).
Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape.
Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Partition page length is 16 
bytes.
Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 1, 
psum 03, pofmetc 4, rec 03, units 09, sizes: 2543 38
Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: psd_cnt 2, max.parts 3, 
nbr_parts 1
Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Formatting tape with two 
partitions (FDP).
Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Sent partition page length 
is 12 bytes. needs_format: 1
Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 4, 
psum 00, pofmetc 4, rec 03, units 00, sizes: 65535 0
Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Error: 802, cmd: 15 10 
0 0 18 0
Dec 30 19:26:12 shakuhachi kernel: st0: Sense Key : Illegal Request [current] 
Dec 30 19:26:12 shakuhachi kernel: st0: Add. Sense: Invalid field in parameter 
list
Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Partitioning of tape failed.







-- 

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: st driver doesn't seem to grok LTO partitioning

2015-12-30 Thread Kai Makisara
On Tuesday 2015-12-29 20:13, Emmanuel Florac wrote:

...
>It works when providing the size :
>
># mt -f /dev/nst0  mkpartition 36764
>
Good.

I think I found out why it did not work with the default format. At the 
end of this message you find a new patch that should correct that. There 
are also other changes:
- some changes when specifying the size in the mode page; needed for the
  IBM 3592 drives but should not change results with LTO
- formatting with one partition is done directly with FORMAT MEDIUM if
  the drive requires that command
- some other bugs fixed

Thanks for testing,
Kai

---8<
--- ref/drivers/scsi/st.c   2015-12-21 18:54:05.068882001 +0200
+++ new/drivers/scsi/st.c   2015-12-30 19:30:37.900152216 +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 = "20151230";
 
 #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,15 @@
and 10 when 1 partition is defined (information from Eric Lee Green). This 
is
is acceptable also to some other old drives and enforced if the first 
partition
size field is used for the first additional partition size.
+
+   For drives that advertize SCSI-3 or newer, use the SSC-3 methods.
  */
 static int partition_tape(struct scsi_tape *STp, int size)
 {
int result;
+   bool scsi3 = STp->device->scsi_level >= SCSI_3,  needs_format = false;
int pgo, psd_cnt, psdo;
+   int psum = PP_MSK_PSUM_MB, units = 0;
unsigned char *bp;
 
result = read_mode_page(STp, PART_PAGE, 0);
@@ -3357,11 +3387,54 @@
pgo = MODE_HEADER_LENGTH + bp[MH_OFF_BDESCS_LENGTH];
DEBC_printk(STp, "Partition page length is %d bytes.\n",
bp[pgo + MP_OFF_PAGE_LENGTH] + 2);
+   DEBC_printk(STp, "PP: max %u, add %u, xdp %u, psum %02x, pofmetc %u, "
+   "rec %02x, units %02x, sizes: %u %u\n",
+   bp[pgo + PP_OFF_MAX_ADD_PARTS],
+   bp[pgo + PP_OFF_NBR_ADD_PARTS],
+   (bp[pgo + PP_OFF_FLAGS] & 0xe0) >> 5,
+   (bp[pgo + PP_OFF_FLAGS] & 0x18) >> 3,
+   bp[pgo + PP_OFF_FLAGS] & 0x07,
+   bp[pgo + 5],
+   bp[pgo + PP_OFF_PART_UNITS],
+   bp[pgo + 8] * 256 + bp[pgo + 9],
+   bp[pgo + 10] * 256 + bp[pgo + 11]);
+
+   if (scsi3) {
+   needs_format = (bp[pgo + PP_OFF_FLAGS] & PP_MSK_POFM) != 0;
+   if (needs_format && size == 0) {
+   result = format_medium(STp, 0);
+   goto out;
+   }
+
+   psd_cnt = size > 0 ? 2 : 1;
+   if ((bp[pgo + PP_OFF_FLAGS] & PP_MSK_PSUM_UNITS) == 
PP_MSK_PSUM_UNITS) {
+   /* Use units scaling for large partitions if the device 
suggests
+  it and no precision lost. Required for IBM TS1140/50 
drives
+  that don't support MB units. */
+   if (size >= 1000 && (size % 1000) == 0) {
+   size /= 1000;
+   psum = PP_MSK_PSUM_UNITS;
+   units = 9; /* GB */
+   }
+   }
+   /* Try it anyway if too large to specify in MB */
+   if (psum == PP_MSK_PSUM_MB 

Re: st driver doesn't seem to grok LTO partitioning

2015-12-29 Thread Emmanuel Florac
Le Tue, 29 Dec 2015 19:46:11 +0200
"Kai Mäkisara (Kolumbus)"  écrivait:

> It seems that you have not told the st driver that your drive knows
> partitions. One way to set the options is to use the stint program
> and proper definitions. You can also use mtst -f /dev/nst0
> stsetoption can-partitions
> 

Silly me. I forgot that one.

> The st driver prints some debugging data to the kernel log if
> debugging is enabled. If the driver is compiled with debugging (it is
> nowadays default but in 3.18 you should change DEBUG to 1 in st.c).

Yup this is the output from the driver with DEBUG at 1. 

> The debugging output can be enabled with the command: mtst
> -f /dev/nst0 stsetoption debug

Ah yes, it works!

> Regardless whether the partitioning works with your drive, your
> should see at least few lines after “Rewinding tape”. The driver
> first reads the partition mode page and (for testing) prints some
> data from the page.

So here is the result of my testings so far. Alas, it fails on the
goal line!:

# mt -f /dev/st0  stsetoption debug


Dec 29 17:57:38 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 
bytes.
Dec 29 17:57:38 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Dec 29 17:57:38 shakuhachi kernel: st 7:0:0:0: st0: Density 58, tape length: 0, 
drv buffer: 1
Dec 29 17:57:38 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 
4096 (1 blocks).
Dec 29 18:51:45 shakuhachi kernel: st 7:0:0:0: st0: Error: 802, cmd: 0 0 0 
0 0 0
Dec 29 18:51:45 shakuhachi kernel: st0: Sense Key : Unit Attention [current] 
Dec 29 18:51:45 shakuhachi kernel: st0: Add. Sense: Not ready to ready change, 
medium may have changed
Dec 29 18:51:45 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 
bytes.
Dec 29 18:51:45 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Dec 29 18:51:45 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, 
drv buffer: 1
Dec 29 18:51:45 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 
4096 (1 blocks).
Dec 29 18:51:45 shakuhachi kernel: st 7:0:0:0: st0: Mode 0 options: buffer 
writes: 1, async writes: 1, read ahead: 1
Dec 29 18:51:45 shakuhachi kernel: st 7:0:0:0: st0: can bsr: 1, two FMs: 0, 
fast mteom: 0, auto lock: 0,
Dec 29 18:51:45 shakuhachi kernel: st 7:0:0:0: st0: defs for wr: 0, no 
block limits: 0, partitions: 0, s2 log: 0
Dec 29 18:51:45 shakuhachi kernel: st 7:0:0:0: st0: sysv: 0 nowait: 0 sili: 
0 nowait_filemark: 0
Dec 29 18:51:45 shakuhachi kernel: st 7:0:0:0: st0: debugging: 1
Dec 29 18:51:45 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape.

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

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

Dec 29 18:54:04 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 
bytes.
Dec 29 18:54:04 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Dec 29 18:54:04 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, 
drv buffer: 1
Dec 29 18:54:04 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 
4096 (1 blocks).
Dec 29 18:54:04 shakuhachi kernel: st 7:0:0:0: st0: Updating partition number 
in status.
Dec 29 18:54:04 shakuhachi kernel: st 7:0:0:0: st0: Got tape pos. blk 0 part 0.
Dec 29 18:54:04 shakuhachi kernel: st 7:0:0:0: st0: Mode 0 options: buffer 
writes: 1, async writes: 1, read ahead: 1
Dec 29 18:54:04 shakuhachi kernel: st 7:0:0:0: st0: can bsr: 1, two FMs: 0, 
fast mteom: 0, auto lock: 0,
Dec 29 18:54:04 shakuhachi kernel: st 7:0:0:0: st0: defs for wr: 0, no 
block limits: 0, partitions: 1, s2 log: 0
Dec 29 18:54:04 shakuhachi kernel: st 7:0:0:0: st0: sysv: 0 nowait: 0 sili: 
0 nowait_filemark: 0
Dec 29 18:54:04 shakuhachi kernel: st 7:0:0:0: st0: debugging: 1
Dec 29 18:54:04 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape.

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

Dec 29 18:55:54 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 
bytes.
Dec 29 18:55:54 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Dec 29 18:55:54 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, 
drv buffer: 1
Dec 29 18:55:54 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 
4096 (1 blocks).
Dec 29 18:55:54 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape.
Dec 29 18:55:54 shakuhachi kernel: st 7:0:0:0: st0: Partition page length is 16 
bytes.
Dec 29 18:55:54 shakuhachi kernel: st 7:0:0:0:

Re: st driver doesn't seem to grok LTO partitioning

2015-12-29 Thread Kai Mäkisara (Kolumbus)

> On 29.12.2015, at 18.58, Emmanuel Florac  wrote:
> 
> Le Fri, 25 Dec 2015 17:53:46 +0200 (EET)
> Kai Makisara  écrivait:
> 
>> The patch uses the scsi level of the device to separate processing.
>> The FORMAT MEDIUM command is defined in SCSI-3 and I suppose that no
>> current drive is still SCSI-2. In addition to the "sane" changes
>> using the method to specify partitions, the patch implements the
>> following: if the size is 1, the driver tells the drive to use
>> default partitioning for two partitions. For the HP Ultrium this
>> should result in partition 0 of 1425 GB and 1 of 37.5 GB. I don't
>> know if this is a useful addition.
> 
> Still testing, with another, LTO-5 tape:
> 
> ~# mt -f /dev/nst0 mkpartition 0
> /dev/nst0: Invalid argument
> 
It seems that you have not told the st driver that your drive knows partitions. 
One way to set the
options is to use the stint program and proper definitions. You can also use
mtst -f /dev/nst0 stsetoption can-partitions

> Dec 29 17:57:38 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 
> bytes.
> Dec 29 17:57:38 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, 
> medium 0, WBS 10, BLL 8
> Dec 29 17:57:38 shakuhachi kernel: st 7:0:0:0: st0: Density 58, tape length: 
> 0, drv buffer: 1
> Dec 29 17:57:38 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer 
> size: 4096 (1 blocks).
> 
The st driver prints some debugging data to the kernel log if debugging is 
enabled. If the driver
is compiled with debugging (it is nowadays default but in 3.18 you should 
change DEBUG to 1
in st.c). The debugging output can be enabled with the command:
mtst -f /dev/nst0 stsetoption debug

Here is the debugging output when I make a 10 MB partition with my drive:
[ 2199.572546] st 4:0:5:0: [st0] Block limits 1 - 16777215 bytes.
[ 2199.573367] st 4:0:5:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[ 2199.573375] st 4:0:5:0: [st0] Density 26, tape length: 0, drv buffer: 1
[ 2199.573380] st 4:0:5:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
[ 2199.573403] st 4:0:5:0: [st0] Rewinding tape.
[ 2199.575319] st 4:0:5:0: [st0] Partition page length is 10 bytes.
[ 2199.575328] st 4:0:5:0: [st0] PP: max 1, add 1, xdp 0, psum 02, pofmetc 
0,rec 03 units 00, sizes: 100 65535
[ 2199.575333] st 4:0:5:0: [st0] psd_cnt 1, max.parts 1, nbr_parts 1
[ 2199.575338] st 4:0:5:0: [st0] Formatting tape with two partitions (1 = 10 
MB).
[ 2199.575342] st 4:0:5:0: [st0] Sent partition page length is 10 bytes. 
needs_format: 0
[ 2199.575348] st 4:0:5:0: [st0] PP: max 1, add 1, xdp 1, psum 02, pofmetc 
0,rec 03 units 00, sizes: 10 65535

Regardless whether the partitioning works with your drive, your should see at 
least few lines after “Rewinding tape”.
The driver first reads the partition mode page and (for testing) prints some 
data from the page.

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: st driver doesn't seem to grok LTO partitioning

2015-12-29 Thread Kai Mäkisara (Kolumbus)

> On 29.12.2015, at 18.59, Emmanuel Florac  wrote:
> 
> Le Fri, 25 Dec 2015 17:53:46 +0200 (EET)
> Kai Makisara  écrivait:
> 
>> the patch implements the following: if the 
>> size is 1, the driver tells the drive to use default partitioning for 
>> two partitions. For the HP Ultrium this should result in partition 0
>> of 1425 GB and 1 of 37.5 GB. I don't know if this is a useful
>> addition.
> 
> Oh BTW I didn't check what's happening in code, but actual values
> should be 37.5 GB for partition 0 and 1425 GB for partition 1, not the
> other way around.
> 

What I quoted is from the HP manual. The driver tells the drive to format
the tape according to the default of the drive (i.e., sets the FDP bit in the
mode page).

The order of partitions is an interesting question. The usual use case is
to have a small partition for the index and a large partition for the data.
The small partition should positioned so that it can be accessed fast. For
the old really linear drives this means the beginning. It was decided that
the first partition on the tape was given number one and the second
partition had the number zero. The HP LTO seems to use this numbering
for the default.

The SCSI standard does not specify how the partitions should be numbered.
Many drives use physically sequential numbering nowadays. LTO uses
wrap-wise partitioning and I don’t think locations of the partitions have any
effect on access speed.

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: st driver doesn't seem to grok LTO partitioning

2015-12-29 Thread Emmanuel Florac
Le Fri, 25 Dec 2015 17:53:46 +0200 (EET)
Kai Makisara  écrivait:

> the patch implements the following: if the 
> size is 1, the driver tells the drive to use default partitioning for 
> two partitions. For the HP Ultrium this should result in partition 0
> of 1425 GB and 1 of 37.5 GB. I don't know if this is a useful
> addition.

Oh BTW I didn't check what's happening in code, but actual values
should be 37.5 GB for partition 0 and 1425 GB for partition 1, not the
other way around.

-- 

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: st driver doesn't seem to grok LTO partitioning

2015-12-29 Thread Emmanuel Florac
Le Fri, 25 Dec 2015 17:53:46 +0200 (EET)
Kai Makisara  écrivait:

> The patch uses the scsi level of the device to separate processing.
> The FORMAT MEDIUM command is defined in SCSI-3 and I suppose that no
> current drive is still SCSI-2. In addition to the "sane" changes
> using the method to specify partitions, the patch implements the
> following: if the size is 1, the driver tells the drive to use
> default partitioning for two partitions. For the HP Ultrium this
> should result in partition 0 of 1425 GB and 1 of 37.5 GB. I don't
> know if this is a useful addition.

Still testing, with another, LTO-5 tape:

~# mt -f /dev/nst0 mkpartition 0
/dev/nst0: Invalid argument

Dec 29 17:57:38 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 
bytes.
Dec 29 17:57:38 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Dec 29 17:57:38 shakuhachi kernel: st 7:0:0:0: st0: Density 58, tape length: 0, 
drv buffer: 1
Dec 29 17:57:38 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 
4096 (1 blocks).


-- 

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: st driver doesn't seem to grok LTO partitioning

2015-12-29 Thread Emmanuel Florac
Le Fri, 25 Dec 2015 17:53:46 +0200 (EET)
Kai Makisara  écrivait:

> The patch uses the scsi level of the device to separate processing.
> The FORMAT MEDIUM command is defined in SCSI-3 and I suppose that no
> current drive is still SCSI-2. In addition to the "sane" changes
> using the method to specify partitions, the patch implements the
> following: if the size is 1, the driver tells the drive to use
> default partitioning for two partitions. For the HP Ultrium this
> should result in partition 0 of 1425 GB and 1 of 37.5 GB. I don't
> know if this is a useful addition.
> 

I didn't look much at the code, but here's what's happening when
running "mt -f /dev/st0 mkpartition 1":

Dec 29 17:01:53 shakuhachi kernel: st: Version 20151225, fixed bufsize 32768, 
s/g segs 256
Dec 29 17:01:53 shakuhachi kernel: st 7:0:0:0: Attached scsi tape st0
Dec 29 17:01:53 shakuhachi kernel: st 7:0:0:0: st0: try direct i/o: yes 
(alignment 512 B)
Dec 29 17:01:53 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 
bytes.
Dec 29 17:01:53 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Dec 29 17:01:53 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, 
drv buffer: 1
Dec 29 17:01:53 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 
4096 (1 blocks).
Dec 29 17:02:04 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 
bytes.
Dec 29 17:02:04 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Dec 29 17:02:04 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, 
drv buffer: 1
Dec 29 17:02:04 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 
4096 (1 blocks).
Dec 29 17:02:04 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape.
Dec 29 17:03:06 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 
bytes.
Dec 29 17:03:06 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, 
medium 0, WBS 10, BLL 8
Dec 29 17:03:06 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, 
drv buffer: 1
Dec 29 17:03:06 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 
4096 (1 blocks).
Dec 29 17:07:20 shakuhachi kernel: st 7:0:0:0: st0: Error: 802,cmd: 0 0 0 0 
0 0

Note that I've simply patched my plain vanilla 3.18.25 st modules.
There doesn't seem to be any difference with newer (or older) kernels,
anyway.

Do you want me to try anything in particular? Is my mt version OK (v
1.1)?

-- 

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: st driver doesn't seem to grok LTO partitioning

2015-12-25 Thread Emmanuel Florac
Le Fri, 25 Dec 2015 17:53:46 +0200 (EET)
Kai Makisara  écrivait:

> The patch at the end of this message is an attempt to make the 
> partitioning work for both old and new drives. The patch is against
> st.c from the current git kernel, although I have tested it in 4.3.3.
> It seems to work with my HP DDS-4 drive. It includes some debugging
> printks and I have tried to see that the commands that would have
> been sent to newer drives are basically correct.
> 
> The patch uses the scsi level of the device to separate processing.
> The FORMAT MEDIUM command is defined in SCSI-3 and I suppose that no
> current drive is still SCSI-2. In addition to the "sane" changes
> using the method to specify partitions, the patch implements the
> following: if the size is 1, the driver tells the drive to use
> default partitioning for two partitions. For the HP Ultrium this
> should result in partition 0 of 1425 GB and 1 of 37.5 GB. I don't
> know if this is a useful addition.

Great I'll give it a try soon next week!

-- 

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: st driver doesn't seem to grok LTO partitioning

2015-12-25 Thread Kai Makisara
On Monday 2015-12-21 20:57, "Kai Mäkisara (Kolumbus)" wrote:

...
>I can look at the manuals during Christmas holidays and try to think about a 
>suggestion.
>All other suggestions are, of course, welcome. My view may be somewhat 
>theoretical
>because I don’t have access to current hardware.
>
I have had some time to look at manuals and even do some coding :-)

The partitioning is initiated with the MTMKPART operation of the 
MTIOCTOP ioctl. This has one int parameter mt_count that is used to 
specify the size in megabytes of the first partition on the tape. Note 
that, for historical reasons, the number of this partition used to be 1, 
not zero. So, the ioctls allocates the specified space to partition 1 
and the rest to partition 0. This intefarce does not allow specifying 
more than two partitions. We can make work for current drives quite 
easily. More than two partitions need a new API but do we have a real 
need for this?

The current code did not work basically because the current drives need 
a separate FORMAT MEDIUM command to do the partitioning specified by 
MODE SELECT. There are smaller details that could have also been a 
problem.

The patch at the end of this message is an attempt to make the 
partitioning work for both old and new drives. The patch is against st.c 
from the current git kernel, although I have tested it in 4.3.3. It 
seems to work with my HP DDS-4 drive. It includes some debugging printks 
and I have tried to see that the commands that would have been sent to 
newer drives are basically correct.

The patch uses the scsi level of the device to separate processing. The 
FORMAT MEDIUM command is defined in SCSI-3 and I suppose that no current 
drive is still SCSI-2. In addition to the "sane" changes using the 
method to specify partitions, the patch implements the following: if the 
size is 1, the driver tells the drive to use default partitioning for 
two partitions. For the HP Ultrium this should result in partition 0 of 
1425 GB and 1 of 37.5 GB. I don't know if this is a useful addition.


Kai

8<--
--- ref/drivers/scsi/st.c   2015-12-21 18:54:05.068882001 +0200
+++ new/drivers/scsi/st.c   2015-12-25 16:49:54.345263675 +0200
@@ -17,7 +17,7 @@
Last modified: 18-JAN-1998 Richard Gooch  Devfs 
support
  */
 
-static const char *verstr = "20101219";
+static const char *verstr = "20151225";
 
 #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. */
@@ -3344,7 +3347,9 @@
 static int partition_tape(struct scsi_tape *STp, int size)
 {
int result;
+   int scsi3 = STp->device->scsi_level >= SCSI_3, needs_format = 0;
int pgo, psd_cnt, psdo;
+   int psum = PP_MSK_PSUM_MB, units = 0;
unsigned char *bp;
 
result = read_mode_page(STp, PART_PAGE, 0);
@@ -3357,10 +3362,32 @@
pgo = MODE_HEADER_LENGTH + bp[MH_OFF_BDESCS_LENGTH];
DEBC_printk(STp, "Partition page length is %d bytes.\n",
bp[pgo + MP_OFF_PAGE_LENGTH] + 2);
-
-   psd_cnt = (bp[pgo + MP_OFF_PAGE_LENGTH] + 2 - PART_PAGE_FIXED_LENGTH) / 
2;
+   DEBC_printk(STp, "PP: max %u, add %u, xdp %u, psum %02x, pofmetc %u,"
+   "rec %02x units %02x, sizes: %u %u\n",
+   bp[pgo + PP_OFF_MAX_ADD_PARTS],
+   bp[pgo + PP_OFF_NBR_ADD_PARTS],
+   (bp[pgo + PP_OFF_FLAGS] & 0xe0) >> 5,
+   (bp[pgo + PP_OFF_FLAGS] & 0x18) >> 3,
+   bp[pgo + PP_OFF_FLAGS] & 0x03,
+   bp[pgo + 5],
+   bp[pgo + PP_OFF_PART_UNITS],
+   bp[pgo + 8] * 256 + bp[pgo + 9],
+   bp[pgo + 10] * 256 + bp[pgo + 11]);
+
+   if (scsi3) {
+   psd_cnt = size > 0 ? 2 : 1;
+   if (size >= 65535) {
+   size /= 1000;
+   psum = PP_MSK_PSUM_UNITS;
+   units = 9; /* GB */
+   }
+   } else
+   psd_cnt = (bp[pgo + MP_OFF_PAGE_LENGTH] + 2 -
+  PART_PAGE_FIXED_LENGTH) / 2;
+   if (size >= 65535)
+   return -EINVAL;
psdo = pgo + PART_PAGE_FIXED_LENGTH;
-   if (psd_cnt > bp[pgo + PP_OFF_MAX_ADD_PARTS]) {
+   if (scsi3 || psd_cnt > bp[pgo + PP_OFF_MAX_ADD_PARTS]) {
bp[psdo] = bp[psdo + 1] = 0xff;  /* Rest of the tape */
psdo += 2;
}
@@ -3375,6 +3402,11 @@
if (psd_cnt <= bp[pgo + PP_OFF_MAX_ADD_PARTS])
bp[pgo + MP_OFF_PAGE_LENGTH] = 6;
DEBC_printk(STp, "Formatting tape with one partition.\n");
+   } else if (siz

Re: st driver doesn't seem to grok LTO partitioning

2015-12-22 Thread Laurence Oberman
I am just waiting on some LTO5 tape cartridges and then will start
working on this.
I only have LTO cartridges so had to order a couple of LTO5's

On Tue, Dec 22, 2015 at 5:04 AM, Emmanuel Florac  wrote:
> Le Tue, 22 Dec 2015 02:20:31 -0500
> Laurence Oberman  écrivait:
>
>> I also have access to newer hardware if needed. I have started
>> reviewing all of this and will post back to this thread.
>> Emmanuel can you summarize what you would like to achieve and we will
>> all work on this together.
>
> I'd like to be able to partition LTO media through standard commands,
> like "mt mkpartition", mostly to be able to create LTFS tapes without
> relying on hard to compile code from IBM/HP/Quantum/Oracle.
>
> --
> 
> 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: st driver doesn't seem to grok LTO partitioning

2015-12-22 Thread Emmanuel Florac
Le Tue, 22 Dec 2015 02:20:31 -0500
Laurence Oberman  écrivait:

> I also have access to newer hardware if needed. I have started
> reviewing all of this and will post back to this thread.
> Emmanuel can you summarize what you would like to achieve and we will
> all work on this together.

I'd like to be able to partition LTO media through standard commands,
like "mt mkpartition", mostly to be able to create LTFS tapes without
relying on hard to compile code from IBM/HP/Quantum/Oracle.

-- 

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: st driver doesn't seem to grok LTO partitioning

2015-12-22 Thread Emmanuel Florac
Le Tue, 22 Dec 2015 05:51:30 +
"Seymour, Shane M"  écrivait:

> If you need help with anything please let me know I'd be more than
> happy to contribute (with testing and a review if you want). I have a
> system with an older LTO-3 tape drive that I can use any time (it
> doesn’t support partitioning so if nothing else I can make sure
> partitioning attempts fail gracefully). I may be able to beg, borrow,
> or steal access to an LTO 5 or 6 drive though to help out in testing.

ATM I have an HP LTO-5 and IBM LTO-6 drives (there are real differences
in behaviour between these at times). I need to check what media I have
available for tests though.

> Kai, for the source of the HPE EverStore software should be available
> here:
> 
> http://h20564.www2.hpe.com/hpsc/swd/public/readIndex?sp4ts.oid=5111617

The IBM driver should be here:
http://www-933.ibm.com/support/fixcentral/swg/quickorder?parent=ibm~ST~Tapedevicedriversandsoftware&product=ibm/Storage_Tape/Tape+device+drivers&release=1.0&platform=Linux&function=all&source=fc

When you have selected RH as a platform, the source rpm is also
available to download.

> 
> This seems to be the relevant code from the driver though (the same
> download has the ibm tape driver as well). You'll need to look at the
> following:
> 
> ltotape.c - ltotape_readposition to determine the current partition
> ltotape.c - ltotape_locate - to move to a position on tape (includes
> setting the partition and has a special flag for changing partitions
> between the two it supports if required) ltotape.c - ltotape_format -
> for creating and destroying partitions ltotape.c -
> ltotape_remaining_capacity - will get you the remaining and maximum
> capacity for the partitions
> 
> When you look at those functions you'll see TC_FORMAT_TYPE referenced
> this is the enum referred it is in src/libltfs/tape_ops.h:
> 
> typedef enum {
> TC_FORMAT_DEFAULT   = 0x00,   /* Make 1 partition medium */
> TC_FORMAT_PARTITION = 0x01,   /* Make 2 partition medium */
> TC_FORMAT_DEST_PART = 0x02,   /* Destroy all data and make 2
> partition medium */ TC_FORMAT_MAX   = 0x03
> } TC_FORMAT_TYPE;/* Space command operations */
 
> The driver at that download looks like it only supports two
> partitions though and if you go looking around the code (grep for
> partition) some LTO drives (probably older ones) look like they may
> be partition aware but may not actually support partitions, see this
> comment:
> 
> ltotape_platform.c:  * For an LTO drive, need to determine
> whether it is partition-capable or only partition-aware:

The IBM code however looks like it supports any number of partitions
(though LTO-6/7 support only 4,so MAX_SUPPORTED_PARTITIONS is set to 4):

if(copy_from_user((void*)usr_part, (void*)arg,
sizeof(struct tape_partition))) {
printk("lin_tape_create_partition: cannot copy from user\n");
rc = -EFAULT;
goto EXIT_LABEL;
} /* if */

if(usr_part->number_of_partitions > MAX_SUPPORTED_PARTITIONS) {
DbgPrint(("lin_tape: too many partitions %d\n",
usr_part->number_of_partitions));
rc = -EINVAL;
goto EXIT_LABEL;
} /* if */


Interestingly it seems to support both wrap partitioning and
longitudinal partitioning (on 3592 drives).

-- 

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: st driver doesn't seem to grok LTO partitioning

2015-12-21 Thread Seymour, Shane M
If you need help with anything please let me know I'd be more than happy to 
contribute (with testing and a review if you want). I have a system with an 
older LTO-3 tape drive that I can use any time (it doesn’t support partitioning 
so if nothing else I can make sure partitioning attempts fail gracefully). I 
may be able to beg, borrow, or steal access to an LTO 5 or 6 drive though to 
help out in testing.

Kai, for the source of the HPE EverStore software should be available here:

http://h20564.www2.hpe.com/hpsc/swd/public/readIndex?sp4ts.oid=5111617

Select something like RHEL7 server from the dropdown on the page that loads 
click on the + in front of "Software - Storage (4)". If you click on the first 
product listed then click on select (at the next screen you will unfortunately 
need to create a HP Passport account) and then you need to give a lot of 
personal information when you get the option to download the source make sure 
you change the pulldown above the download buttons to standard download. The 
version 3.0 source is about 1.2Mb in size (GPL version 2.1).

This seems to be the relevant code from the driver though (the same download 
has the ibm tape driver as well). You'll need to look at the following:

ltotape.c - ltotape_readposition to determine the current partition
ltotape.c - ltotape_locate - to move to a position on tape (includes setting 
the partition and has a special flag for changing partitions between the two it 
supports if required)
ltotape.c - ltotape_format - for creating and destroying partitions
ltotape.c - ltotape_remaining_capacity - will get you the remaining and maximum 
capacity for the partitions

When you look at those functions you'll see TC_FORMAT_TYPE referenced this is 
the enum referred it is in src/libltfs/tape_ops.h:

typedef enum {
TC_FORMAT_DEFAULT   = 0x00,   /* Make 1 partition medium */
TC_FORMAT_PARTITION = 0x01,   /* Make 2 partition medium */
TC_FORMAT_DEST_PART = 0x02,   /* Destroy all data and make 2 partition 
medium */
TC_FORMAT_MAX   = 0x03
} TC_FORMAT_TYPE;/* Space command operations */

The driver at that download looks like it only supports two partitions though 
and if you go looking around the code (grep for partition) some LTO drives 
(probably older ones) look like they may be partition aware but may not 
actually support partitions, see this comment:

ltotape_platform.c:  * For an LTO drive, need to determine whether it is 
partition-capable or only partition-aware:

So you may need to check for firmware that is partition aware but not partition 
capable.

The IBM LTO SCSI reference is nice and long and it looks like you can either 
make SET CAPACITY calls on the currently mounted medium to set the sizes and 
then format the medium it also refers to the medium partition mode page in 
terms of changing the partitioning of the tape.
N�r��yb�X��ǧv�^�)޺{.n�+{���"�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: st driver doesn't seem to grok LTO partitioning

2015-12-21 Thread Kai Mäkisara (Kolumbus)

> On 21.12.2015, at 19.57, Emmanuel Florac  wrote:
> 
> Le Mon, 21 Dec 2015 19:25:27 +0200
> "Kai Mäkisara (Kolumbus)"   écrivait:
> 
>>> 
>>> I'm replying to myself: this is very obviously a limitation of the
>>> st driver. Checking st.c partition_tape() function, it looks like
>>> it only knows of hardware from past century… 
>>> 
>> True, it does support only the methods supported by the drives
>> available to the developers at that time :-) However, I am not any
>> more convinced that partitioning a tape should be done by the kernel
>> driver. A more flexible method would be a user space program using sg
>> (or bsg) driver.
> 
> Yes, that's the way the LTFS utility works. That makes the code of the
> application quite hard to read, though, as partitioning on modern
> drives is pretty complex and requires understanding ugly, unholy SCSI
> commands magic. Then Windows/Cygwin, IBM AIX and maybe others seem to
> implement partitioning at the kernel level.
> 
> Do you suggest the current mkpartition/setpartition scheme should be
> removed instead of enhanced ? :)
> 
I don’t suggest that it should be removed. I just pointed out another 
possibility
to implement the more complex formatting cases. I think that SCSI is well 
defined,
but it offers too many ways to do one thing :-) In user space one can implement
several alternatives but the kernel driver has to choose only one (or move the
complexity to the interface). On the other hand, the kernel driver can allow
anyone (who can access the st device) to partition the tape. A user space
program needs more rights.

If the current interface (MTMKPART) is acceptable, we could enhance the driver
so that it handles properly more drives. I looked at the HP Ultrium SCSI 
reference
and it may not be too complicated (for instance, it needs a separate FORMAT 
MEDIUM
command) . I have also found an IBM reference and others can probably be found.
I can look at the manuals during Christmas holidays and try to think about a 
suggestion.
All other suggestions are, of course, welcome. My view may be somewhat 
theoretical
because I don’t have access to current hardware.

>>> OTOH it seems that Cygwin does that properly... by using
>>> CreateTapePartition, a windows kernel32.dll function. Argh. We'll
>>> have to do the heavy lifting of SCSI commands by hand, then.
>>> 
>>> Where should we post an eventual patch, given that the linux-tape ML
>>> looks like a ghost town? It would also be great to be able to
>>> support more than 2 partitions (LTO-6 and 7 support 4), but that
>>> would require patching the mt utility too, but I don't where it
>>> currently lives :) Any hints welcome.
>>> 
>> This (linux-scsi) is the correct mailing list.
>> 
> 
> OK. As I mentioned, the bizarre IBM lin_tape driver (what use is it?)
> implements the complete scheme properly apparently, in a nice GPL2 code.
> Why they didn't contribute it directly to the st driver is mysterious.
> 
I will look at the driver. HP also seems to have an implementation (for LTFS) 
but
I did not find the code because their web links don’t seem to be uptodate.

>> The correct source code of your mt depends on the version you are
>> using (check the distribution). Not also that the ioctl method for
>> creating partitions available in the kernel supports only up to two
>> partitions. If you want more, you should design a new interface.
> 
> I'm using mt-st on debian, the one that seems to go hand in hand with
> the st driver. Both carry your copyright :)
> 
OK. Then the mt part will not be a problem. I have not updated it “recently”
because the kernel interface has not changed.

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: st driver doesn't seem to grok LTO partitioning

2015-12-21 Thread Emmanuel Florac
Le Mon, 21 Dec 2015 11:20:55 -0500
Laurence Oberman  écrivait:

> The st driver gets a lot of attention actually. Let me look into this
> and get back you.

I've found that the IBM tape driver (lin_tape) implements neat ioctls
for LTO and 3592 tape partitionning. Just in case.

-- 

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: st driver doesn't seem to grok LTO partitioning

2015-12-21 Thread Kai Mäkisara (Kolumbus)

> On 21.12.2015, at 14.46, Emmanuel Florac  wrote:
> 
> Le Fri, 18 Dec 2015 17:06:44 +0100
> Emmanuel Florac  écrivait:
> 
>> 
>> I'm trying to use mt to work with LTO-5 and bigger tapes. Switching
>> partitions works:
>> 
>> # tapeinfo -f /dev/sg1
>> Product Type: Tape Drive
>> Vendor ID: 'HP  '
>> Product ID: 'Ultrium 5-SCSI  '
>> Revision: 'Z61U'
>> Attached Changer API: No
>> SerialNumber: 'HU1249TP88'
>> MinBlock: 1
>> MaxBlock: 16777215
>> SCSI ID: 1
>> SCSI LUN: 0
>> Ready: yes
>> BufferedMode: yes
>> Medium Type: Not Loaded
>> Density Code: 0x58
>> BlockSize: 0
>> DataCompEnabled: yes
>> DataCompCapable: yes
>> DataDeCompEnabled: yes
>> CompType: 0x1
>> DeCompType: 0x1
>> BOP: yes
>> Block Position: 0
>> Partition 0 Remaining Kbytes: 1459056
>> Partition 0 Size in Kbytes: 1459056
>> ActivePartition: 0
>> EarlyWarningSize: 0
>> NumPartitions: 1
>> MaxPartitions: 1
>> Partition0: 38
>> Partition1: 1453
>> 
>> # mt -f /dev/nst0 setpartition 1
>> 
>> 
>> However "mt mkpartition" fails miserably:
>> 
>> # mt -f /dev/nst0 mkpartition 1453
>> /dev/nst0: Input/output error
>> 
>> # dmesg | tail
>> st 6:0:1:0: st0: Failed to read 65536 byte block with 256 byte
>> transfer. st0: Sense Key : Illegal Request [current] 
>> st0: Add. Sense: Invalid field in parameter list
>> 
>> Is this a limitation of mt or the st driver?
>> 
> 
> I'm replying to myself: this is very obviously a limitation of the st
> driver. Checking st.c partition_tape() function, it looks like it only
> knows of hardware from past century… 
> 
True, it does support only the methods supported by the drives available
to the developers at that time :-) However, I am not any more convinced that
partitioning a tape should be done by the kernel driver. A more flexible
method would be a user space program using sg (or bsg) driver.

> OTOH it seems that Cygwin does that properly... by using
> CreateTapePartition, a windows kernel32.dll function. Argh. We'll have
> to do the heavy lifting of SCSI commands by hand, then.
> 
> Where should we post an eventual patch, given that the linux-tape ML
> looks like a ghost town? It would also be great to be able to support
> more than 2 partitions (LTO-6 and 7 support 4), but that would require
> patching the mt utility too, but I don't where it currently lives :)
> Any hints welcome.
> 
This (linux-scsi) is the correct mailing list.

The correct source code of your mt depends on the version you are
using (check the distribution). Not also that the ioctl method for creating
partitions available in the kernel supports only up to two partitions. If
you want more, you should design a new interface.

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: st driver doesn't seem to grok LTO partitioning

2015-12-21 Thread Emmanuel Florac
Le Fri, 18 Dec 2015 17:06:44 +0100
Emmanuel Florac  écrivait:

> 
> I'm trying to use mt to work with LTO-5 and bigger tapes. Switching
> partitions works:
> 
> # tapeinfo -f /dev/sg1
> Product Type: Tape Drive
> Vendor ID: 'HP  '
> Product ID: 'Ultrium 5-SCSI  '
> Revision: 'Z61U'
> Attached Changer API: No
> SerialNumber: 'HU1249TP88'
> MinBlock: 1
> MaxBlock: 16777215
> SCSI ID: 1
> SCSI LUN: 0
> Ready: yes
> BufferedMode: yes
> Medium Type: Not Loaded
> Density Code: 0x58
> BlockSize: 0
> DataCompEnabled: yes
> DataCompCapable: yes
> DataDeCompEnabled: yes
> CompType: 0x1
> DeCompType: 0x1
> BOP: yes
> Block Position: 0
> Partition 0 Remaining Kbytes: 1459056
> Partition 0 Size in Kbytes: 1459056
> ActivePartition: 0
> EarlyWarningSize: 0
> NumPartitions: 1
> MaxPartitions: 1
> Partition0: 38
> Partition1: 1453
> 
> # mt -f /dev/nst0 setpartition 1
> 
> 
> However "mt mkpartition" fails miserably:
> 
> # mt -f /dev/nst0 mkpartition 1453
> /dev/nst0: Input/output error
> 
> # dmesg | tail
> st 6:0:1:0: st0: Failed to read 65536 byte block with 256 byte
> transfer. st0: Sense Key : Illegal Request [current] 
> st0: Add. Sense: Invalid field in parameter list
> 
> Is this a limitation of mt or the st driver?
> 

I'm replying to myself: this is very obviously a limitation of the st
driver. Checking st.c partition_tape() function, it looks like it only
knows of hardware from past century... 

OTOH it seems that Cygwin does that properly... by using
CreateTapePartition, a windows kernel32.dll function. Argh. We'll have
to do the heavy lifting of SCSI commands by hand, then.

Where should we post an eventual patch, given that the linux-tape ML
looks like a ghost town? It would also be great to be able to support
more than 2 partitions (LTO-6 and 7 support 4), but that would require
patching the mt utility too, but I don't where it currently lives :)
Any hints welcome.

-- 

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