Re: st driver doesn't seem to grok LTO partitioning [coming back 2 and a half years later]
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)
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
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
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
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
> 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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
> 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
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
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
> 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
> 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
: [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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
> 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
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
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
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
> 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
> 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
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
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
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
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
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
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
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
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
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
> 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
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
> 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
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
