Scalar i40 tapechanger LUN appearing as a second tape drive

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Scalar i40 tapechanger LUN appearing as a second tape drive

Dirk-Willem van Gulik
While having to re-surrect a Quantum Scalar i40 LTO5 unit - on a stock  11.1-RELEASE-p6  wired up with a external SAS cable to a HP Smart Array P222 I am seeing:

        camcontrol devlist
        ...
        <HP Ultrium 5-SCSI Z6KZ>           at scbus3 target 4 lun 0 (sa0,pass1)
        <HP Ultrium 5-SCSI Z6KZ>           at scbus3 target 4 lun 1 (pass2,sa1)
        ....

rather than the tape drive on LUN 0 and the tape changer on LUN 1 (the control path is to this drive - the serial number matches - and in like with the web interface details).

dmesg shows:

        ...
        sa0 at ciss1 bus 32 scbus3 target 4 lun 0
        sa0: Serial Number C38CEFF000
        ...
        sa1 at ciss1 bus 32 scbus3 target 4 lun 1
        ...
        sa1: Serial Number C38CEFF000

The second drive (Serial C38CEFF004) is not wired up. Or if it is - it nicely shows up at the right (different) target and LUN0, without a second LUN.

Does this ring a bell with any one ? The kernel has ch(4), sa(4) and pass(4) compiled in statically (and is known to work with other tape changers/libraries).

Any hints appreciated,

Dw.


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Scalar i40 tapechanger LUN appearing as a second tape drive

Ken Merry
On Sun, May 13, 2018 at 20:00:21 +0200, Dirk-Willem van Gulik wrote:

> While having to re-surrect a Quantum Scalar i40 LTO5 unit - on a stock  11.1-RELEASE-p6  wired up with a external SAS cable to a HP Smart Array P222 I am seeing:
>
> camcontrol devlist
> ...
> <HP Ultrium 5-SCSI Z6KZ>           at scbus3 target 4 lun 0 (sa0,pass1)
> <HP Ultrium 5-SCSI Z6KZ>           at scbus3 target 4 lun 1 (pass2,sa1)
> ....
>
> rather than the tape drive on LUN 0 and the tape changer on LUN 1 (the control path is to this drive - the serial number matches - and in like with the web interface details).
>
> dmesg shows:
>
> ...
> sa0 at ciss1 bus 32 scbus3 target 4 lun 0
> sa0: Serial Number C38CEFF000
> ...
> sa1 at ciss1 bus 32 scbus3 target 4 lun 1
> ...
> sa1: Serial Number C38CEFF000
>
> The second drive (Serial C38CEFF004) is not wired up. Or if it is - it nicely shows up at the right (different) target and LUN0, without a second LUN.
>
> Does this ring a bell with any one ? The kernel has ch(4), sa(4) and pass(4) compiled in statically (and is known to work with other tape changers/libraries).
>

When you hooked other tape changers up, was it to the same machine, and
also to the ciss(4) controller?  Was the configuration the same?

It looks like the array controller is moving things around.

I would suggest taking a look at configuration options for the controller
to see if you can adjust the way it does passthrough.

Or, if you can find one, put a standard SAS controller in there (as opposed
to a RAID controller) and hook that up to the tape library.

It is unlikely that FreeBSD is causing this behavior.  It really looks like
the RAID controller is giving you multiple copies of the same tape drive.

Ken
--
Kenneth Merry
[hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Scalar i40 tapechanger LUN appearing as a second tape drive

Dirk-Willem van Gulik

> On 15 May 2018, at 22:19, Kenneth D. Merry <[hidden email]> wrote:
>
> On Sun, May 13, 2018 at 20:00:21 +0200, Dirk-Willem van Gulik wrote:
>> While having to re-surrect a Quantum Scalar i40 LTO5 unit - on a stock  11.1-RELEASE-p6  wired up with a external SAS cable to a HP Smart Array P222 I am seeing:
>>
>> camcontrol devlist
>> ...
>> <HP Ultrium 5-SCSI Z6KZ>           at scbus3 target 4 lun 0 (sa0,pass1)
>> <HP Ultrium 5-SCSI Z6KZ>           at scbus3 target 4 lun 1 (pass2,sa1)
>> ....
>>
>> rather than the tape drive on LUN 0 and the tape changer on LUN 1 (the control path is to this drive - the serial number matches - and in like with the web interface details).
>>
>> dmesg shows:
>>
>> ...
>> sa0 at ciss1 bus 32 scbus3 target 4 lun 0
>> sa0: Serial Number C38CEFF000
>> ...
>> sa1 at ciss1 bus 32 scbus3 target 4 lun 1
>> ...
>> sa1: Serial Number C38CEFF000
>>
>> The second drive (Serial C38CEFF004) is not wired up. Or if it is - it nicely shows up at the right (different) target and LUN0, without a second LUN.
>>
>> Does this ring a bell with any one ? The kernel has ch(4), sa(4) and pass(4) compiled in statically (and is known to work with other tape changers/libraries).
>>
>
> When you hooked other tape changers up, was it to the same machine, and
> also to the ciss(4) controller?  Was the configuration the same?

Yes (but *).

> It looks like the array controller is moving things around.
>
> I would suggest taking a look at configuration options for the controller
> to see if you can adjust the way it does passthrough.

The control-path can indeed be set. It is set correctly (we also tried the 3 other permutations possible).

> Or, if you can find one, put a standard SAS controller in there (as opposed
> to a RAID controller) and hook that up to the tape library.

Ok. good advice. Will do exactly that.

> It is unlikely that FreeBSD is causing this behavior.  It really looks like
> the RAID controller is giving you multiple copies of the same tape drive.

Thanks. The odd thing is that this very configuration/card/etc has worked around 8.x.

Dw

*: the Quantum Scalar i40’s have the annoying habit to self-check their firmware and prime themselves for auto update with a fairly easy to miss cancel prompt on the screen. So we are not a 100% it was not updated during the re-racking by someone going through the re-calibration mindlessly.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Scalar i40 tapechanger LUN appearing as a second tape drive

Ken Merry
On Wed, May 16, 2018 at 10:48:54 +0200, Dirk-Willem van Gulik wrote:

>
> > On 15 May 2018, at 22:19, Kenneth D. Merry <[hidden email]> wrote:
> >
> > On Sun, May 13, 2018 at 20:00:21 +0200, Dirk-Willem van Gulik wrote:
> >> While having to re-surrect a Quantum Scalar i40 LTO5 unit - on a stock  11.1-RELEASE-p6  wired up with a external SAS cable to a HP Smart Array P222 I am seeing:
> >>
> >> camcontrol devlist
> >> ...
> >> <HP Ultrium 5-SCSI Z6KZ>           at scbus3 target 4 lun 0 (sa0,pass1)
> >> <HP Ultrium 5-SCSI Z6KZ>           at scbus3 target 4 lun 1 (pass2,sa1)
> >> ....
> >>
> >> rather than the tape drive on LUN 0 and the tape changer on LUN 1 (the control path is to this drive - the serial number matches - and in like with the web interface details).
> >>
> >> dmesg shows:
> >>
> >> ...
> >> sa0 at ciss1 bus 32 scbus3 target 4 lun 0
> >> sa0: Serial Number C38CEFF000
> >> ...
> >> sa1 at ciss1 bus 32 scbus3 target 4 lun 1
> >> ...
> >> sa1: Serial Number C38CEFF000
> >>
> >> The second drive (Serial C38CEFF004) is not wired up. Or if it is - it nicely shows up at the right (different) target and LUN0, without a second LUN.
> >>
> >> Does this ring a bell with any one ? The kernel has ch(4), sa(4) and pass(4) compiled in statically (and is known to work with other tape changers/libraries).
> >>
> >
> > When you hooked other tape changers up, was it to the same machine, and
> > also to the ciss(4) controller?  Was the configuration the same?
>
> Yes (but *).
>
> > It looks like the array controller is moving things around.
> >
> > I would suggest taking a look at configuration options for the controller
> > to see if you can adjust the way it does passthrough.
>
> The control-path can indeed be set. It is set correctly (we also tried the 3 other permutations possible).
>

Ok.  Perhaps the RAID controller firmware was updated since the last time
you did this, and it doesn't work as well as it used to work.

> > Or, if you can find one, put a standard SAS controller in there (as opposed
> > to a RAID controller) and hook that up to the tape library.
>
> Ok. good advice. Will do exactly that.

The best controllers to use are LSI (now Broadcom) 6Gb or 12Gb SAS
controllers.  They have TLR support, which helps insure data integrity with
tape drives.

> > It is unlikely that FreeBSD is causing this behavior.  It really looks like
> > the RAID controller is giving you multiple copies of the same tape drive.
>
> Thanks. The odd thing is that this very configuration/card/etc has worked around 8.x.
>

Yeah, it is odd.  Perhaps the ciss driver got updated, or perhaps the RAID
firmware got updated.  In any case, a standard SAS controller should
eliminate the problem.  (Spectra Logic ships LSI controllers for use with
tape libraries, so I know that works.)

>
> *: the Quantum Scalar i40???s have the annoying habit to self-check their firmware and prime themselves for auto update with a fairly easy to miss cancel prompt on the screen. So we are not a 100% it was not updated during the re-racking by someone going through the re-calibration mindlessly.

Ahh, interesting.

Ken
--
Kenneth Merry
[hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Scalar i40 tapechanger LUN appearing as a second tape drive

Dirk-Willem van Gulik
On 16 May 2018, at 18:53, Kenneth D. Merry <[hidden email]> wrote:

>> Ok. good advice. Will do exactly that.
>
> The best controllers to use are LSI (now Broadcom) 6Gb or 12Gb SAS
> controllers.  They have TLR support, which helps insure data integrity with
> tape drives.

Ok - we surely have a few  SAS9201 and LSIA SAS9202’s around.

Dw.


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Scalar i40 tapechanger LUN appearing as a second tape drive

Dirk-Willem van Gulik

> On 16 May 2018, at 19:30, Dirk-Willem van Gulik <[hidden email]> wrote:
>
> On 16 May 2018, at 18:53, Kenneth D. Merry <[hidden email]> wrote:
>
>>> Ok. good advice. Will do exactly that.
>>
>> The best controllers to use are LSI (now Broadcom) 6Gb or 12Gb SAS
>> controllers.  They have TLR support, which helps insure data integrity with
>> tape drives.
>
> Ok - we surely have a few  SAS9201 and LSIA SAS9202’s around.

Ok - So the summary is that 1) indeed the LSI controller see the Scalar i40 changer with no issue (and gives us a nice speed update). And that 2) that there may be some regression in the cam/scsi stack -- restoring a FreeBSD-8-RELEASE makes the P222 see the changer again.

Next up - finding out what is wrong with LEOM (and amanda).

Dw.

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Scalar i40 tapechanger LUN appearing as a second tape drive

Ken Merry
On Tue, Jun 05, 2018 at 19:28:54 +0200, Dirk-Willem van Gulik wrote:

>
> > On 16 May 2018, at 19:30, Dirk-Willem van Gulik <[hidden email]> wrote:
> >
> > On 16 May 2018, at 18:53, Kenneth D. Merry <[hidden email]> wrote:
> >
> >>> Ok. good advice. Will do exactly that.
> >>
> >> The best controllers to use are LSI (now Broadcom) 6Gb or 12Gb SAS
> >> controllers.  They have TLR support, which helps insure data integrity with
> >> tape drives.
> >
> > Ok - we surely have a few  SAS9201 and LSIA SAS9202???s around.
>
> Ok - So the summary is that 1) indeed the LSI controller see the Scalar i40 changer with no issue (and gives us a nice speed update). And that 2) that there may be some regression in the cam/scsi stack -- restoring a FreeBSD-8-RELEASE makes the P222 see the changer again.
>

I'm glad things work with the LSI controller!

That is strange that FreeBSD 8 works with the ciss(4) controller and 11.1
doesn't.  I would guess that something changed in the ciss(4) driver, but I
don't see anything really obvious in the logs.

> Next up - finding out what is wrong with LEOM (and amanda).

You're having problems with Amanda?

Ken
--
Kenneth Merry
[hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Scalar i40 tapechanger LUN appearing as a second tape drive

Dirk-Willem van Gulik
On 5 Jun 2018, at 20:07, Kenneth D. Merry <[hidden email]> wrote:
>
>> Next up - finding out what is wrong with LEOM (and amanda).
>
> You're having problems with Amanda?

Somehow amtapetype does not detect LEOM on LTO5 with amanda 3.3.9. Which seems a bit silly.

Checking with 3.5.1 now (as ports stops at 3.3.9); just in case.

Dw.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Scalar i40 tapechanger LUN appearing as a second tape drive

Ken Merry
On Tue, Jun 05, 2018 at 22:25:20 +0200, Dirk-Willem van Gulik wrote:
> On 5 Jun 2018, at 20:07, Kenneth D. Merry <[hidden email]> wrote:
> >
> >> Next up - finding out what is wrong with LEOM (and amanda).
> >
> > You're having problems with Amanda?
>
> Somehow amtapetype does not detect LEOM on LTO5 with amanda 3.3.9. Which seems a bit silly.
>

Amanda shouldn't be doing anything unusual in reading the tape, but it's
possible that its detection logic isn't quite right.

For what it's worth, here's what I'm using in my amanda.conf as a tapetype
with an IBM LTO-5 drive on 3.3.9:

define tapetype LTO-5 {
        comment "LTO 5"
        length 2000000 mbytes
        filemark 0 kbytes
        speed 150000 kps
        part_size 150000 mbytes
        part_cache_type disk
        part_cache_dir "/scratch/amanda"
        part_cache_max_size 150000 mbytes
}

Note that the length is intentionally longer than the 1.5TB raw tape
capacity.  With compression, we get at least that or more, and that helps
keep Amanda from thinking it needs too many tapes.

> Checking with 3.5.1 now (as ports stops at 3.3.9); just in case.

I would suggest just use the above tapetype or a derivative and don't worry
about whether amtapetype is doing the right thing.

Ken
--
Kenneth Merry
[hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[hidden email]"