SCSI tape access on 2.6 kernels?

SCSI tape access on 2.6 kernels?

[Gerhard Schneider]

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]


It's getting me mad..

It seems that with 2.6 (compared to 2.4) there has something been
changed in the kernel that I'm not aware of so I'm not able to
write/read tapes efficiently anymore..

LSI1030 SCSI controller
Overland tape library
Seagate LTO-1 tape drive

Kernel 2.4.29:

dd if=linux-2.6.16-rc1.tar.gz of=/dev/nst0 bs=64k
776+1 records in
776+1 records out
50918460 bytes transferred in 4.620612 seconds (11019852 bytes/sec)

Kernel 2.6.14rc1:

dd if=linux-2.6.16-rc1.tar.gz of=/dev/nst0 bs=64k
776+1 records in
776+1 records out
50918460 bytes transferred in 20.395567 seconds (2496545 bytes/sec)

Another machine w/
LSI1030 SCSI controller
Megaraid ZCR controller
Overland tape library
HP LTO-3 tape drive
Kernel 2.6.14rc1:

dd if=linux-2.6.16-rc1.tar.gz of=/dev/nst0 bs=64k
776+1 records in
776+1 records out
50918460 bytes transferred in 45.953133 seconds (1108052 bytes/sec)

Either there is an initialization problems with tape drives on 2.6.*
(I don't think so) or there are tunable kernel parameters that
I don't know..

CPU load on 2.6 is minimal, tape is waiting for data..

Any idea? (I can provide you with any amount of data etc..)

                                            GS

-- 
Gerhard Schneider
Institute of Lightweight Design and          e-Mail:gs@ilsb.tuwien.ac.at
Structural Biomechanics (E317)                 Tel.:   +43 1 58801 31716
Vienna University of Technology / Austria      Fax:    +43 1 58801 31799
A-1040 Wien, Gusshausstrasse 27-29     http://www.ilsb.tuwien.ac.at/~gs/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: SCSI tape access on 2.6 kernels?

[Gerhard Schneider]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

Gerhard Schneider wrote:
> It's getting me mad..
> 

> 
> Another machine w/
> LSI1030 SCSI controller
> Megaraid ZCR controller
> Overland tape library
> HP LTO-3 tape drive
> Kernel 2.6.14rc1:
> 
> dd if=linux-2.6.16-rc1.tar.gz of=/dev/nst0 bs=64k
> 776+1 records in
> 776+1 records out
> 50918460 bytes transferred in 45.953133 seconds (1108052 bytes/sec)
> 

After installing an old 53c875 controller on the machine w/ 2.6.14rc1:

dd if=linux-2.6.16-rc1.tar.gz of=/dev/nst0 bs=64k
776+1 records in
776+1 records out
50918460 bytes transferred in 27.565659 seconds (1847170 bytes/sec)

Perhaps a 53c810 would be the fastest? What am I doing wrong?

                                   Gerhard Schneider

-- 
Gerhard Schneider
Institute of Lightweight Design and          e-Mail:gs@ilsb.tuwien.ac.at
Structural Biomechanics (E317)                 Tel.:   +43 1 58801 31716
Vienna University of Technology / Austria      Fax:    +43 1 58801 31799
A-1040 Wien, Gusshausstrasse 27-29     http://www.ilsb.tuwien.ac.at/~gs/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: SCSI tape access on 2.6 kernels?

[Chip Coldwell]

On Tue, 24 Jan 2006, Gerhard Schneider wrote:

>
> It's getting me mad..
>
> It seems that with 2.6 (compared to 2.4) there has something been
> changed in the kernel that I'm not aware of so I'm not able to
> write/read tapes efficiently anymore..

Put

options st try_direct_io=0

in /etc/modprobe.conf.  Direct I/O defeats read-ahead, and
significantly (factor of >5) degrates read performance.  I don't know
about writes.

Chip

-- 
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"

Re: SCSI tape access on 2.6 kernels?

[Patrick Mansfield]

On Tue, Jan 24, 2006 at 12:52:36PM -0500, Chip Coldwell wrote:

> Put
> 
> options st try_direct_io=0

> 
> in /etc/modprobe.conf.  Direct I/O defeats read-ahead, and
> significantly (factor of >5) degrates read performance.  I don't know
> about writes.

For tape???

-- Patrick Mansfield

Re: SCSI tape access on 2.6 kernels?

[Chip Coldwell]

On Tue, 24 Jan 2006, Patrick Mansfield wrote:

> On Tue, Jan 24, 2006 at 12:52:36PM -0500, Chip Coldwell wrote:
>
>> Put
>>
>> options st try_direct_io=0
>
>>
>> in /etc/modprobe.conf.  Direct I/O defeats read-ahead, and
>> significantly (factor of >5) degrates read performance.  I don't know
>> about writes.
>
> For tape???

Yes, for tape.  We verified this with a DAT72 DDS drive.

Chip

-- 
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc

Re: SCSI tape access on 2.6 kernels?

[Kai Makisara]

On Tue, 24 Jan 2006, Chip Coldwell wrote:

> On Tue, 24 Jan 2006, Patrick Mansfield wrote:
> 
> > On Tue, Jan 24, 2006 at 12:52:36PM -0500, Chip Coldwell wrote:
> >
> > > Put
> > >
> > > options st try_direct_io=0
> >
> > >
> > > in /etc/modprobe.conf.  Direct I/O defeats read-ahead, and
> > > significantly (factor of >5) degrates read performance.  I don't know
> > > about writes.
> >
> > For tape???
> 
> Yes, for tape.  We verified this with a DAT72 DDS drive.
> 
How did you do the tests? I would like to be able to reproduce this 
finding because there is something wrong somewhere. With any decent read() 
and write() byte counts (the 64 kB you mention in another message is 
decent) you should not find direct i/o slower than using the driver 
buffer. I have not seen anything like this with my DDS-4 drive (same 
speed as DAT72).

-- 
Kai

Re: SCSI tape access on 2.6 kernels?

[Chip Coldwell]

On Wed, 25 Jan 2006, Kai Makisara wrote:

> On Tue, 24 Jan 2006, Chip Coldwell wrote:
>
>> On Tue, 24 Jan 2006, Patrick Mansfield wrote:
>>
>>> On Tue, Jan 24, 2006 at 12:52:36PM -0500, Chip Coldwell wrote:
>>>
>>>> Put
>>>>
>>>> options st try_direct_io=0
>>>
>>>>
>>>> in /etc/modprobe.conf.  Direct I/O defeats read-ahead, and
>>>> significantly (factor of >5) degrates read performance.  I don't know
>>>> about writes.
>>>
>>> For tape???
>>
>> Yes, for tape.  We verified this with a DAT72 DDS drive.
>>
> How did you do the tests? I would like to be able to reproduce this
> finding because there is something wrong somewhere. With any decent read()
> and write() byte counts (the 64 kB you mention in another message is
> decent) you should not find direct i/o slower than using the driver
> buffer. I have not seen anything like this with my DDS-4 drive (same
> speed as DAT72).

We used an Adaptec HBA connected to a DAT72 drive with nothing else on
the bus:

scsi1 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 1.3.10-RH1

Host: scsi1 Channel: 00 Id: 06 Lun: 00
   Vendor: SEAGATE  Model: DAT    DAT72-000 Rev: A060
   Type:   Sequential-Access                ANSI SCSI revision: 03

Target 6 Negotiation Settings
         User: 320.000MB/s transfers (160.000MHz DT|IU|QAS, 16bit)
         Goal: 80.000MB/s transfers (40.000MHz, 16bit)
         Curr: 80.000MB/s transfers (40.000MHz, 16bit)
         Transmission Errors 0
         Channel A Target 6 Lun 0 Settings
                 Commands Queued 6
                 Commands Active 0
                 Command Openings 1
                 Max Tagged Openings 0
                 Device Queue Frozen Count 0

This is using the Red Hat Enterprise Linux v4 kernel (2.6.9-27.ELsmp),
which differs from the latest 2.6, in particular in the st driver.  (I
could test the latest 2.6 and will do so if you think it could make a
difference).

I put some zeros on the tape

RHEL4# dd if=/dev/zero of=/dev/st0 bs=1k count=1000000

and test read performance, first without direct I/O

RHEL4# cat /sys/bus/scsi/drivers/st/try_direct_io 
0
RHEL4# time dd if=/dev/nst0 of=/dev/null bs=1k
1000000+0 records in
1000000+0 records out

real    2m35.418s
user    0m0.639s
sys     0m5.804s

and then with direct I/O

RHEL4# cat /sys/bus/scsi/drivers/st/try_direct_io 
1
RHEL4# time dd if=/dev/nst0 of=/dev/null bs=1k
1000000+0 records in
1000000+0 records out

real    5m1.899s
user    0m1.224s
sys     0m16.456s

so with direct I/O, read performance is about a factor of two slower.
I believe this is because the driver doesn't do read-ahead when doing
direct I/O (after all, how could it?).

I did the test again with larger blocks (the buffer in the tape drive
is 32K), first without direct I/O

RHEL4# cat /sys/bus/scsi/drivers/st/try_direct_io 
0
RHEL4# time dd if=/dev/nst0 of=/dev/null bs=32k
31250+0 records in
31250+0 records out

real    2m30.688s
user    0m0.028s
sys     0m2.871s

then again with direct I/O

RHEL4# time dd if=/dev/nst0 of=/dev/null bs=32k
31250+0 records in
31250+0 records out

real    2m30.687s
user    0m0.063s
sys     0m0.677s

So in this case, performance is no worse or better with direct I/O
than without.

Chip

-- 
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc

Re: SCSI tape access on 2.6 kernels?

[Chip Coldwell]

On Thu, 26 Jan 2006, Chip Coldwell wrote:
>
> then again with direct I/O
>
> RHEL4# time dd if=/dev/nst0 of=/dev/null bs=32k
> 31250+0 records in
> 31250+0 records out
>
> real    2m30.687s
> user    0m0.063s
> sys     0m0.677s
>
> So in this case, performance is no worse or better with direct I/O
> than without.

I tried it again with direct I/O and an even larger block size, but
the time is the same:

RHEL4# time dd if=/dev/nst0 of=/dev/null bs=64k
15625+0 records in
15625+0 records out

real    2m30.153s
user    0m0.025s
sys     0m0.452s

Chip

-- 
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc

Dead Adaptec AHA-2940U2/U2W while ripping a CD

[Mathieu Chouquet-Stringer]

        Hello,

I was ripping a (copy protected) cd on my alpha and got the following
stuff (see below). At that point, the box failed to respond and because I
don't have a console, I rebooted it.

Kernel version is (vanilla 2.6.15):
Linux alpha 2.6.15 #1 Sat Jan 7 16:32:48 CET 2006 alpha EV56 EB164 GNU/Linux

Here's the lspci entry for the card:
01:01.0 SCSI storage controller: Adaptec AHA-2940U2/U2W
        Subsystem: Adaptec AHA-2940U2 SCSI Controller
        Flags: bus master, medium devsel, latency 32, IRQ 26
        BIST result: 00
        I/O ports at 9000 [disabled] [size=256]
        Memory at 09200000 (64-bit, non-prefetchable) [size=4K]
        [virtual] Expansion ROM at 09640000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 1

If you want me to test anything let me know.

Cheers,

Jan 26 18:23:06 alpha sr 1:0:6:0: Attempting to queue an ABORT message
Jan 26 18:23:06 alpha CDB: 0xbe 0x4 0x0 0x2 0x78 0x11 0x0 0x0 0x5 0xf8 0x0 0x0
Jan 26 18:23:06 alpha scsi1: At time of recovery, card was not paused
Jan 26 18:23:06 alpha >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
Jan 26 18:23:06 alpha scsi1: Dumping Card State while idle, at SEQADDR 0x9
Jan 26 18:23:06 alpha Card was paused
Jan 26 18:23:06 alpha ACCUM = 0x0, SINDEX = 0x0, DINDEX = 0xe4, ARG_2 = 0x0
Jan 26 18:23:06 alpha HCNT = 0x0 SCBPTR = 0x1d
Jan 26 18:23:06 alpha SCSISIGI[0x0] ERROR[0x0] SCSIBUSL[0x0] LASTPHASE[0x1]:(P_BUSFREE) 
Jan 26 18:23:06 alpha SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) SBLKCTL[0xa]:(SELWIDE|SELBUSB) 
Jan 26 18:23:06 alpha SCSIRATE[0x0] SEQCTL[0x10]:(FASTMODE) SEQ_FLAGS[0xc0]:(NO_CDB_SENT|NOT_IDENTIFIED) 
Jan 26 18:23:06 alpha SSTAT0[0x0] SSTAT1[0xa]:(PHASECHG|BUSFREE) SSTAT2[0x0] 
Jan 26 18:23:06 alpha SSTAT3[0x0] SIMODE0[0x8]:(ENSWRAP) SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) 
Jan 26 18:23:06 alpha SXFRCTL0[0x80]:(DFON) DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) 
Jan 26 18:23:06 alpha STACK: 0x0 0x167 0x10d 0x3
Jan 26 18:23:06 alpha SCB count = 56
Jan 26 18:23:06 alpha Kernel NEXTQSCB = 19
Jan 26 18:23:06 alpha Card NEXTQSCB = 19
Jan 26 18:23:06 alpha QINFIFO entries: 
Jan 26 18:23:06 alpha Waiting Queue entries: 
Jan 26 18:23:06 alpha Disconnected Queue entries: 18:24 
Jan 26 18:23:06 alpha QOUTFIFO entries: 
Jan 26 18:23:06 alpha Sequencer Free SCB List: 29 0 24 13 5 10 6 8 21 19 4 11 1 7 23 26 15 9 12 28 3 31 25 16 27 17 30 20 22 14 2 
Jan 26 18:23:06 alpha Sequencer SCB Info: 
Jan 26 18:23:06 alpha 0 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 1 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 2 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 3 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 4 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 5 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 6 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 7 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 8 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 9 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 10 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 11 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 12 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 13 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 14 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 15 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 16 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 17 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 18 SCB_CONTROL[0x44]:(DISCONNECTED|DISCENB) SCB_SCSIID[0x67] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0x18] 
Jan 26 18:23:06 alpha 19 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 20 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 21 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 22 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 23 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 24 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x27] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 25 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x27] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 26 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 27 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 28 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 29 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 30 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha 31 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] 
Jan 26 18:23:06 alpha SCB_LUN[0x0] SCB_TAG[0xff] 
Jan 26 18:23:06 alpha Pending list: 
Jan 26 18:23:06 alpha 24 SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0x67] SCB_LUN[0x0] 
Jan 26 18:23:06 alpha Kernel Free SCB list: 0 35 47 42 40 46 10 12 20 26 31 3 7 14 8 18 27 17 34 15 21 5 33 1 11 29 23 25 6 30 38 16 4 9 39 13 41 43 54 44 45 37 32 55 28 22 36 2 53 52 51 50 49 48 
Jan 26 18:23:06 alpha Untagged Q(6): 24 
Jan 26 18:23:06 alpha 
Jan 26 18:23:06 alpha <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>>
Jan 26 18:23:06 alpha (scsi1:A:6:0): Device is disconnected, re-queuing SCB
Jan 26 18:23:06 alpha (scsi1:A:6:0): Abort Message Sent
Jan 26 18:23:06 alpha Recovery code sleeping
Jan 26 18:23:11 alpha Recovery code awake
Jan 26 18:23:11 alpha Timer Expired
Jan 26 18:23:11 alpha aic7xxx_abort returns 0x2003
Jan 26 18:23:11 alpha sr 1:0:6:0: Attempting to queue a TARGET RESET message
Jan 26 18:23:11 alpha CDB: 0xbe 0x4 0x0 0x2 0x78 0x11 0x0 0x0 0x5 0xf8 0x0 0x0
Jan 26 18:23:11 alpha aic7xxx_dev_reset returns 0x2003
Jan 26 18:23:11 alpha Recovery SCB completes

-- 
Mathieu Chouquet-Stringer
    "Le disparu, si l'on vénère sa mémoire, est plus présent et
                 plus puissant que le vivant".
           -- Antoine de Saint-Exupéry, Citadelle --
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SCSI tape access on 2.6 kernels?

[Kai Makisara]

On Thu, 26 Jan 2006, Chip Coldwell wrote:

> On Wed, 25 Jan 2006, Kai Makisara wrote:
> 
> > On Tue, 24 Jan 2006, Chip Coldwell wrote:
> >
> > > On Tue, 24 Jan 2006, Patrick Mansfield wrote:
> > >
> > > > On Tue, Jan 24, 2006 at 12:52:36PM -0500, Chip Coldwell wrote:
> > > >
> > > > > Put
> > > > >
> > > > > options st try_direct_io=0
> > > >
> > > > >
> > > > > in /etc/modprobe.conf.  Direct I/O defeats read-ahead, and
> > > > > significantly (factor of >5) degrates read performance.  I don't know
> > > > > about writes.
> > > >
> > > > For tape???
> > >
> > > Yes, for tape.  We verified this with a DAT72 DDS drive.
> > >
> > How did you do the tests? I would like to be able to reproduce this
> > finding because there is something wrong somewhere. With any decent read()
> > and write() byte counts (the 64 kB you mention in another message is
> > decent) you should not find direct i/o slower than using the driver
> > buffer. I have not seen anything like this with my DDS-4 drive (same
> > speed as DAT72).
> 
> We used an Adaptec HBA connected to a DAT72 drive with nothing else on
> the bus:
> 
> scsi1 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 1.3.10-RH1
> 
> Host: scsi1 Channel: 00 Id: 06 Lun: 00
>   Vendor: SEAGATE  Model: DAT    DAT72-000 Rev: A060
>   Type:   Sequential-Access                ANSI SCSI revision: 03
> 
> Target 6 Negotiation Settings
>         User: 320.000MB/s transfers (160.000MHz DT|IU|QAS, 16bit)
>         Goal: 80.000MB/s transfers (40.000MHz, 16bit)
>         Curr: 80.000MB/s transfers (40.000MHz, 16bit)
>         Transmission Errors 0
>         Channel A Target 6 Lun 0 Settings
>                 Commands Queued 6
>                 Commands Active 0
>                 Command Openings 1
>                 Max Tagged Openings 0
>                 Device Queue Frozen Count 0
> 
You did not say whether the drive was in fixed block mode ('mt status' 
tell nonzero block size) of variable block mode. The Seagate (now Quantum) 
drives usually wake up in fixed block mode with 1024 byte block size. I am 
assuming this is the case here.

Compression seems to be enabled because you get speeds that exceed the 3.5 
MB/s native speed of the drive. You are measuring here more the speed of 
the drive's processor than the tape reading performance. However, this 
does not invalidate the results of these tests.

> This is using the Red Hat Enterprise Linux v4 kernel (2.6.9-27.ELsmp),
> which differs from the latest 2.6, in particular in the st driver.  (I
> could test the latest 2.6 and will do so if you think it could make a
> difference).
> 
The version does not matter. The basic st behaviour is similar in all 2.6 
kernels.

> I put some zeros on the tape
> 
> RHEL4# dd if=/dev/zero of=/dev/st0 bs=1k count=1000000
> 
> and test read performance, first without direct I/O
> 
> RHEL4# cat /sys/bus/scsi/drivers/st/try_direct_io 0

This command tells the current settings (and probably says that the file 0 
does not exist). With the stock kernel you have to rmmod and modprobe the 
st module. But I think we know what you mean to say here.

> RHEL4# time dd if=/dev/nst0 of=/dev/null bs=1k
> 1000000+0 records in
> 1000000+0 records out
> 
> real    2m35.418s
> user    0m0.639s
> sys     0m5.804s
> 
> and then with direct I/O
> 
> RHEL4# cat /sys/bus/scsi/drivers/st/try_direct_io 1
> RHEL4# time dd if=/dev/nst0 of=/dev/null bs=1k
> 1000000+0 records in
> 1000000+0 records out
> 
> real    5m1.899s
> user    0m1.224s
> sys     0m16.456s
> 
> so with direct I/O, read performance is about a factor of two slower.
> I believe this is because the driver doesn't do read-ahead when doing
> direct I/O (after all, how could it?).
> 
I repeated these tests with a HP DAT40 connected to a LSI Logic 53c1010 
HBA. The kernel was 2.6.16-rc1-git4.

The tests in fixed block mode showed similar behaviour with slightly 
different times (6m10 vs 1m6). (In variable block mode the time was 6m10 
with both try_direct_io=1 and try_direct_io=0).

Your analysis here is correct. This is also the case I mentioned in 
another message where I said that disabling direct i/o increases speed in 
fixed block mode: the read() and write() byte counts are very small.

The problem is that this case is testing something that you should never 
do with a tape. No even half-decent tape application does this. The 
nearest I know is tar with the default 10 kB block size.

You should _not draw any practical conclusions on this test_!

> I did the test again with larger blocks (the buffer in the tape drive
> is 32K), first without direct I/O
> 
> RHEL4# cat /sys/bus/scsi/drivers/st/try_direct_io 0
> RHEL4# time dd if=/dev/nst0 of=/dev/null bs=32k
> 31250+0 records in
> 31250+0 records out
> 
> real    2m30.688s
> user    0m0.028s
> sys     0m2.871s
> 
> then again with direct I/O
> 
> RHEL4# time dd if=/dev/nst0 of=/dev/null bs=32k
> 31250+0 records in
> 31250+0 records out
> 
> real    2m30.687s
> user    0m0.063s
> sys     0m0.677s
> 
> So in this case, performance is no worse or better with direct I/O
> than without.
> 
This is a more realistic test. The 32 kB i/o size is large enough for many 
drives. In another message you prove this for the DAT72 because you did 
not get better speed with 64 kB i/o size. (The drive manufacturers usually 
provide a suggestion for the optimal i/o size.)

-- 
Kai

Re: SCSI tape access on 2.6 kernels?

[Chip Coldwell]

On Thu, 26 Jan 2006, Kai Makisara wrote:
>
> You did not say whether the drive was in fixed block mode ('mt status'
> tell nonzero block size) of variable block mode. The Seagate (now Quantum)
> drives usually wake up in fixed block mode with 1024 byte block size. I am
> assuming this is the case here.

Close, but with 512 byte fixed blocks by default:

RHEL4# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=1, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x47 (TR-5).
Soft error count since last status=0
General status bits on (81010000):
  EOF ONLINE IM_REP_EN

> Compression seems to be enabled because you get speeds that exceed the 3.5
> MB/s native speed of the drive. You are measuring here more the speed of
> the drive's processor than the tape reading performance. However, this
> does not invalidate the results of these tests.

Good point; a file entirely comprised of zeros should compress very
well.  So I repeated the experiments with compression off.  First,
with direct I/O

RHEL4# time dd if=/dev/nst0 of=/dev/null bs=1k
1000000+0 records in
1000000+0 records out

real    10m34.332s
user    0m1.136s
sys     0m16.209s

then again without it

RHEL4# time dd if=/dev/nst0 of=/dev/null bs=1k
1000000+0 records in
1000000+0 records out

real    4m47.364s
user    0m0.655s
sys     0m5.780s

> I repeated these tests with a HP DAT40 connected to a LSI Logic 53c1010
> HBA. The kernel was 2.6.16-rc1-git4.
>
> The tests in fixed block mode showed similar behaviour with slightly
> different times (6m10 vs 1m6). (In variable block mode the time was 6m10
> with both try_direct_io=1 and try_direct_io=0).

So are you saying that the best time in the experiments you did (1m6)
is without direct I/O using fixed blocks?  This is nearly six times
faster than fixed blocks with direct I/O, or variable blocks in either
case.

> Your analysis here is correct. This is also the case I mentioned in
> another message where I said that disabling direct i/o increases speed in
> fixed block mode: the read() and write() byte counts are very small.
>
> The problem is that this case is testing something that you should never
> do with a tape. No even half-decent tape application does this. The
> nearest I know is tar with the default 10 kB block size.

Well, the default mode of the tape drive when it comes up is a 512
byte fixed block size.  tar, cpio and dump all use fixed block sizes
by default.  So it seems that the default behavior is "something that
you should never do with a tape".  I would argue that this is a
problem.

>> I did the test again with larger blocks (the buffer in the tape drive
>> is 32K), first without direct I/O
>>
>> RHEL4# cat /sys/bus/scsi/drivers/st/try_direct_io 0
>> RHEL4# time dd if=/dev/nst0 of=/dev/null bs=32k
>> 31250+0 records in
>> 31250+0 records out
>>
>> real    2m30.688s
>> user    0m0.028s
>> sys     0m2.871s
>>
>> then again with direct I/O
>>
>> RHEL4# time dd if=/dev/nst0 of=/dev/null bs=32k
>> 31250+0 records in
>> 31250+0 records out
>>
>> real    2m30.687s
>> user    0m0.063s
>> sys     0m0.677s
>>
>> So in this case, performance is no worse or better with direct I/O
>> than without.
>>
> This is a more realistic test. The 32 kB i/o size is large enough for many
> drives. In another message you prove this for the DAT72 because you did
> not get better speed with 64 kB i/o size. (The drive manufacturers usually
> provide a suggestion for the optimal i/o size.)

Granted, but in the best possible case, using direct I/O gives the
same performance as not using it; and in all other cases it is much
worse.  Can you describe a configuration I can test where direct I/O
makes the performance better?

Chip

-- 
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc

Re: SCSI tape access on 2.6 kernels?

[Kai Makisara]

On Fri, 27 Jan 2006, Chip Coldwell wrote:

...
> > Compression seems to be enabled because you get speeds that exceed the 3.5
> > MB/s native speed of the drive. You are measuring here more the speed of
> > the drive's processor than the tape reading performance. However, this
> > does not invalidate the results of these tests.
> 
> Good point; a file entirely comprised of zeros should compress very
> well.  So I repeated the experiments with compression off.  First,
> with direct I/O
> 
> RHEL4# time dd if=/dev/nst0 of=/dev/null bs=1k
> 1000000+0 records in
> 1000000+0 records out
> 
> real    10m34.332s
> user    0m1.136s
> sys     0m16.209s
> 
> then again without it
> 
> RHEL4# time dd if=/dev/nst0 of=/dev/null bs=1k
> 1000000+0 records in
> 1000000+0 records out
> 
> real    4m47.364s
> user    0m0.655s
> sys     0m5.780s
> 
The raw speed of the drive is 3.5 MB/s. Reading 1 GB should take 4m45.6. 
Your result with read-ahead matches this. Doing 1 kB SCSI transfers slows 
down things (and causes "shoeshining" that further decreases speed).

> > I repeated these tests with a HP DAT40 connected to a LSI Logic 53c1010
> > HBA. The kernel was 2.6.16-rc1-git4.
> >
> > The tests in fixed block mode showed similar behaviour with slightly
> > different times (6m10 vs 1m6). (In variable block mode the time was 6m10
> > with both try_direct_io=1 and try_direct_io=0).
> 
> So are you saying that the best time in the experiments you did (1m6)
> is without direct I/O using fixed blocks?  This is nearly six times
> faster than fixed blocks with direct I/O, or variable blocks in either
> case.
> 
Yes, in a meaningless test.

> > Your analysis here is correct. This is also the case I mentioned in
> > another message where I said that disabling direct i/o increases speed in
> > fixed block mode: the read() and write() byte counts are very small.
> >
> > The problem is that this case is testing something that you should never
> > do with a tape. No even half-decent tape application does this. The
> > nearest I know is tar with the default 10 kB block size.
> 
> Well, the default mode of the tape drive when it comes up is a 512
> byte fixed block size.  tar, cpio and dump all use fixed block sizes
> by default.  So it seems that the default behavior is "something that
> you should never do with a tape".  I would argue that this is a
> problem.
> 
The programs don't use fixed or variable block size. They just read and 
write using a fixed byte count. If the tape drive is in fixed block mode, 
the application read/write byte count must be divisible by the block size. 
In variable block mode there are no limitations.

The tar default is 10 kB transfers. This causes slowdown without 
read-ahead in some systems (probably not with your test system). The users 
should use at least 'tar b 64'. cpio default is 5120 and it is really too 
low for tapes.

Most current tape drives come up in variable block mode. Fixed block mode 
is an exception. In an ideal world the user chooses the mode and block 
size that fits the application :-)

...
> > This is a more realistic test. The 32 kB i/o size is large enough for many
> > drives. In another message you prove this for the DAT72 because you did
> > not get better speed with 64 kB i/o size. (The drive manufacturers usually
> > provide a suggestion for the optimal i/o size.)
> 
> Granted, but in the best possible case, using direct I/O gives the
> same performance as not using it; and in all other cases it is much
> worse.  Can you describe a configuration I can test where direct I/O
> makes the performance better?
> 
Direct i/o saves bus cycles by eliminating copy from user space to kernel 
space. It is useful when there are not spare cycles to waste. The typical 
combination, relatively speaking, where this matters is a fast drive (or 
more than one drive) and a not so fast system. The first example that 
comes into my mind is an LTO-3 drive connected to a Celeron system with 
32-bit PCI bus. With this combination yous should see well noticeable 
difference is system time. If you add an application into this system, the 
throughput may not match the tape streaming speed and that is very bad.

I think that direct i/o is the correct default, but I admit that other 
opinions can exist if different weights are given to the different 
situations.

-- 
Kai

Re: SCSI tape access on 2.6 kernels?

[Kai Makisara]

On Tue, 24 Jan 2006, Chip Coldwell wrote:

> On Tue, 24 Jan 2006, Gerhard Schneider wrote:
> 
> >
> > It's getting me mad..
> >
> > It seems that with 2.6 (compared to 2.4) there has something been
> > changed in the kernel that I'm not aware of so I'm not able to
> > write/read tapes efficiently anymore..
> 
> Put
> 
> options st try_direct_io=0
> 
> in /etc/modprobe.conf.  Direct I/O defeats read-ahead, and
> significantly (factor of >5) degrates read performance.  I don't know
> about writes.
> 
The only thing that could be seen in Gerhard's tests with try_direct_io=0 
should be higher CPU load. It probably won't have any effect on the speed 
in these tests.

Disabling direct i/o helps in fixed block mode if the application's read() 
and write() byte counts are small, e.g., 10 kB. With 64 kB it should not 
have any effect. Additionally, Gerhard is probably using variable block 
mode and there is no read-ahead. There is write-behind which is disabled 
when doing direct i/o but this should have no effect since if the HBA is 
able to sustain the speed the drive requires.

-- 
Kai

Re: SCSI tape access on 2.6 kernels?

[Chip Coldwell]

On Tue, 24 Jan 2006, Kai Makisara wrote:
>>
>> Put
>>
>> options st try_direct_io=0
>>
>> in /etc/modprobe.conf.  Direct I/O defeats read-ahead, and
>> significantly (factor of >5) degrates read performance.  I don't know
>> about writes.
>>
> The only thing that could be seen in Gerhard's tests with try_direct_io=0
> should be higher CPU load. It probably won't have any effect on the speed
> in these tests.

I will let Gerhard speak for himself, but it made an enormous
difference in our tests.  The buffer size in the tape device is 64K,
matching the read-ahead to that buffer size gave maximum performance.

Chip

-- 
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc

Re: SCSI tape access on 2.6 kernels?

[Gerhard Schneider]

[-- Attachment #1: Type: text/plain, Size: 1482 bytes --]

Kai Makisara schrieb:

> The only thing that could be seen in Gerhard's tests with try_direct_io=0 
> should be higher CPU load. It probably won't have any effect on the speed 
> in these tests.
> 
> Disabling direct i/o helps in fixed block mode if the application's read() 
> and write() byte counts are small, e.g., 10 kB. With 64 kB it should not 
> have any effect. Additionally, Gerhard is probably using variable block 
> mode and there is no read-ahead. There is write-behind which is disabled 
> when doing direct i/o but this should have no effect since if the HBA is 
> able to sustain the speed the drive requires.
> 

I fear you're right. There hasn't been any significant difference in
write/read speed when enabling/disabling direct i/o (significant doesn't
mean a speedup of 20-100% - I want to see more than 40MB/s on a LTO-3
tape drive, and not 1.2)..

Different fixed and variable block sizes didn't show significant speed
increases, too.. - and I still expect a kernel problem, not a tape
problem..

Tomorrow I will compile a kernel < 2.6.12 and redo testing..

                                             GS

-- 
Gerhard Schneider
Institute of Lightweight Design and         e-Mail: gs@ilsb.tuwien.ac.at
Structural Biomechanics (E317)                 Tel.:   +43 1 58801 31716
Vienna University of Technology / Austria      Fax:    +43 1 58801 31799
A-1040 Wien, Gusshausstrasse 27-29     http://www.ilsb.tuwien.ac.at/~gs/



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: SCSI tape access on 2.6 kernels?

[Chip Coldwell]

On Tue, 24 Jan 2006, Gerhard Schneider wrote:

> Kai Makisara schrieb:
>
>> The only thing that could be seen in Gerhard's tests with try_direct_io=0
>> should be higher CPU load. It probably won't have any effect on the speed
>> in these tests.
>>
>> Disabling direct i/o helps in fixed block mode if the application's read()
>> and write() byte counts are small, e.g., 10 kB. With 64 kB it should not
>> have any effect. Additionally, Gerhard is probably using variable block
>> mode and there is no read-ahead. There is write-behind which is disabled
>> when doing direct i/o but this should have no effect since if the HBA is
>> able to sustain the speed the drive requires.
>>
>
> I fear you're right. There hasn't been any significant difference in
> write/read speed when enabling/disabling direct i/o (significant doesn't
> mean a speedup of 20-100% - I want to see more than 40MB/s on a LTO-3
> tape drive, and not 1.2)..

I'm curious -- what was the impact on performance of disabling direct
I/O in your case?

I agree with Kai that the biggest performance hit is the 20 MB/s
negotiated bus speed.

Chip

-- 
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc

Re: SCSI tape access on 2.6 kernels?

[Denny Page]

I agree.  In my case, the problem is also initial negation: 3 MB/s :-(.

Denny


Chip Coldwell wrote:
> I'm curious -- what was the impact on performance of disabling direct
> I/O in your case?
>
> I agree with Kai that the biggest performance hit is the 20 MB/s
> negotiated bus speed.
>
> Chip
>

Re: SCSI tape access on 2.6 kernels?

[Gerhard Schneider]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

Denny Page schrieb:
> I agree.  In my case, the problem is also initial negation: 3 MB/s :-(.
> 
> Denny
> 

Could be, as I wrote earlier I don't know how to check this on a
Fusion or Megaraid chipset because all I have is
/sys/class/scsi_tape/nst0/device/scsi_level=4
                                /queue_depth=7
                                /queue_type=simple

The 53c8xx drivers are more verbose..

Actually I'm running a full backup (a few TB) on a generic 2.6.11.12
kernel with good performance (>30MB/s) on the LTO-3 tape library on
a 53c1030 controller. That's first priority. After that backup I will
play again with different kernel versions and the other tape library.

Sorry for that delay..

                                             GS
-- 
Gerhard Schneider
Institute of Lightweight Design and         e-Mail: gs@ilsb.tuwien.ac.at
Structural Biomechanics (E317)                 Tel.:   +43 1 58801 31716
Vienna University of Technology / Austria      Fax:    +43 1 58801 31799
A-1040 Wien, Gusshausstrasse 27-29     http://www.ilsb.tuwien.ac.at/~gs/



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: SCSI tape access on 2.6 kernels?

[Denny Page]

Gerhard,

You may want to test earlier versions of 2.6.  There have been various 
reports of problems with scsi tape in later versions of the 2.6 kernel.  
I have problems beginning with 2.6.14 with U320 with LTO-2, others have 
reported problems going back to 2.6.12.

Denny


Gerhard Schneider wrote:
> It's getting me mad..
>
> It seems that with 2.6 (compared to 2.4) there has something been
> changed in the kernel that I'm not aware of so I'm not able to
> write/read tapes efficiently anymore..
>
> LSI1030 SCSI controller
> Overland tape library
> Seagate LTO-1 tape drive
>
> Kernel 2.4.29:
>
> dd if=linux-2.6.16-rc1.tar.gz of=/dev/nst0 bs=64k
> 776+1 records in
> 776+1 records out
> 50918460 bytes transferred in 4.620612 seconds (11019852 bytes/sec)
>
> Kernel 2.6.14rc1:
>
> dd if=linux-2.6.16-rc1.tar.gz of=/dev/nst0 bs=64k
> 776+1 records in
> 776+1 records out
> 50918460 bytes transferred in 20.395567 seconds (2496545 bytes/sec)
>
> Another machine w/
> LSI1030 SCSI controller
> Megaraid ZCR controller
> Overland tape library
> HP LTO-3 tape drive
> Kernel 2.6.14rc1:
>
> dd if=linux-2.6.16-rc1.tar.gz of=/dev/nst0 bs=64k
> 776+1 records in
> 776+1 records out
> 50918460 bytes transferred in 45.953133 seconds (1108052 bytes/sec)
>
> Either there is an initialization problems with tape drives on 2.6.*
> (I don't think so) or there are tunable kernel parameters that
> I don't know..
>
> CPU load on 2.6 is minimal, tape is waiting for data..
>
> Any idea? (I can provide you with any amount of data etc..)
>
>                                             GS
>
>   

Re: SCSI tape access on 2.6 kernels?

[Kai Makisara]

On Tue, 24 Jan 2006, Gerhard Schneider wrote:

> 
> It's getting me mad..
> 
> It seems that with 2.6 (compared to 2.4) there has something been
> changed in the kernel that I'm not aware of so I'm not able to
> write/read tapes efficiently anymore..
> 
> LSI1030 SCSI controller
> Overland tape library
> Seagate LTO-1 tape drive
> 
> Kernel 2.4.29:
> 
> dd if=linux-2.6.16-rc1.tar.gz of=/dev/nst0 bs=64k
> 776+1 records in
> 776+1 records out
> 50918460 bytes transferred in 4.620612 seconds (11019852 bytes/sec)
> 
> Kernel 2.6.14rc1:
> 
> dd if=linux-2.6.16-rc1.tar.gz of=/dev/nst0 bs=64k
> 776+1 records in
> 776+1 records out
> 50918460 bytes transferred in 20.395567 seconds (2496545 bytes/sec)
> 
> Another machine w/
> LSI1030 SCSI controller
> Megaraid ZCR controller
> Overland tape library
> HP LTO-3 tape drive
> Kernel 2.6.14rc1:
> 
> dd if=linux-2.6.16-rc1.tar.gz of=/dev/nst0 bs=64k
> 776+1 records in
> 776+1 records out
> 50918460 bytes transferred in 45.953133 seconds (1108052 bytes/sec)
> 
> Either there is an initialization problems with tape drives on 2.6.*
> (I don't think so) or there are tunable kernel parameters that
> I don't know..
> 
You should not need to tune anything.

> CPU load on 2.6 is minimal, tape is waiting for data..
> 
> Any idea? (I can provide you with any amount of data etc..)
> 
What are the speeds negotiated between the SCSI HBA and the tape drive in 
these cases?

One thing that can affect your comparisons is that the amount of data is 
quite small compared to the drive speed. The startup delay may be a 
significant factor in the timings (it differs depending on where the tape 
is and what has happened before the test). Even taking this into account, 
the speeds you see with 2.6 are too small.

-- 
Kai

Re: SCSI tape access on 2.6 kernels?

[Gerhard Schneider]

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]

Kai Makisara schrieb:

>>
> What are the speeds negotiated between the SCSI HBA and the tape drive in 
> these cases?
> 

I don't have the data for Megaraid and Fusion (both are not very verbose
on startup), for the very old LSI 875 chipset there it comes:


Vendor: HP        Model: Ultrium 3-SCSI    Rev: G24H
Type:   Sequential-Access                  ANSI SCSI revision: 03
target7:0:4: tagged command queuing enabled, command queue depth 16.
target7:0:4: Beginning Domain Validation
target7:0:4: asynchronous.
target7:0:4: Wide Transfers Fail
target7:0:4: asynchronous.
target7:0:4: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16)
target7:0:4: Ending Domain Validation
Attached scsi generic sg9 at scsi7, channel 0, id 4, lun 0,  type 1

I have to investigate why wide negotiation failed (firmware bug - but
they will laugh at me if I ask..), but 20 MB/s should be enough
for more than 1.5 MB/s transfer speed (there are only the tape drive
and the media changer on the bus)

                                      GS

-- 
Gerhard Schneider
Institute of Lightweight Design and         e-Mail: gs@ilsb.tuwien.ac.at
Structural Biomechanics (E317)                 Tel.:   +43 1 58801 31716
Vienna University of Technology / Austria      Fax:    +43 1 58801 31799
A-1040 Wien, Gusshausstrasse 27-29     http://www.ilsb.tuwien.ac.at/~gs/



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: SCSI tape access on 2.6 kernels?

[Kai Makisara]

On Tue, 24 Jan 2006, Kai Makisara wrote:

...
> One thing that can affect your comparisons is that the amount of data is 
> quite small compared to the drive speed. The startup delay may be a 
> significant factor in the timings (it differs depending on where the tape 
> is and what has happened before the test). Even taking this into account, 
> the speeds you see with 2.6 are too small.
> 
I think I said this too weakly ;-) If you want to measure the streaming 
speed of the tape system, the test file must be large enough. It can take 
tens of seconds before a streamer starts writing and this time does vary 
depending on the tape position, tape, has the drive been reading/writing 
before, etc. You can verify this i you can listen what the drive is doing 
during the tests. You can also try writing very small files and measure 
the times.

A rule of thumb might be to have a test data that takes one or more
minutes to read/write. The HP LTO-3 raw speed is 80 MB/s without 
compression. So, for a one minute test you should have 800 MB of 
uncompressible data (or switch compression off).

-- 
Kai