Louis Guillaume wrote:
> Aaron J. Grier wrote:
> 
>>On Tue, Nov 28, 2006 at 09:34:51AM -0800, Chuck Swiger wrote:
>>
>>>On Nov 27, 2006, at 6:03 PM, Aaron J. Grier wrote:
>>>
>>>>the whole dump -> rmt -> tape write interaction ends up going in fits
>>>>and starts.
>>>
>>>Agreed.  Note that you can use dd to rebuffer the output of dump,
>>>which will speed things up considerably, assuming that your version
>>>of dump does not support configuring the blocksize it uses.
>>
>>NetBSD's dump is limited to writing 64K blocks (128 512-byte "tape
>>blocks").
>>
>>I get roughly 600kB/s to my DLT8000 through ssh/rmt with the following
>>invocation:
>>
>>	/sbin/dump -1u -a -b 128 -h 0 -k 64 -r 128 $FILESYSTEM
>>
>>dumping the root filesystem from my alpha to an i386 box (/dev/null)
>>with dump vs star I get the following:
>>
>>dump to /dev/null: 4203 KB/s
>>star to /dev/null: 4116.75 KB/s
>>dump with BSD rmt: 960 KB/s
>>dump with star rmt: 989 KB/s
>>star with star rmt: ~1300 KB/s
>>star with bsd rmt server: 1388.26 KB/s
>>
>>both with 64kB write blocks.  I'll have to try reblocking with dump to
>>see how much difference that makes; thanks for the suggestion.  I know
>>the DLTs can handle very large blocks, up to 16MB I think.
>>
> 
> 
> I'd like to test some of this stuff too; but I'm starting to realize
> that I need to learn more about rmt and these DLT devices. Perhaps you
i could help too..have DLT..came from trashbin. ..
> can help me get past a couple things...
> 
> . What do you use for the density code? I used `85', which
>   is supposed to be 70G compressed according to the manual.
>   But that's supposed to be in hex. And I have no idea what
>   "mt setdensity xx" is supposed to use; 85 or 133. Both
>   are accepted.
> 
>   Anyway, I did an "mt erase" and all hell broke loose. The
>   drive had some bad-looking errors (see below) and it
>   caused the system to hang.
> 
>   How do you configure your DLT8000??
> 
> . What about the tape device? How come we use the raw device
>   /dev/nrst0 rather than the block device /dev/nst0???
> 
> ... If I can figure this stuff out and get reliable backups going, I'd
> be happy to help with documentation specific for NetBSD.
> 
> 
> Louis
> 
> 
> 
> st0: 65536-byte tape record too big for 32768-byte user buffer
> st0(ahc1:0:5:0):  Check Condition on CDB: 0x08 00 00 80 00 00
>     SENSE KEY:  No Additional Sense
>                 Incorrect Length Indicator Set
>    INFO FIELD:  -32768
>  COMMAND INFO:  11700 (0x2db4)
>      ASC/ASCQ:  No Additional Sense Information
> 
> st0: 65536-byte tape record too big for 32768-byte user buffer
> st0(ahc1:0:5:0):  Check Condition on CDB: 0x08 00 00 80 00 00
>     SENSE KEY:  No Additional Sense
>                 Incorrect Length Indicator Set
>    INFO FIELD:  -32768
>  COMMAND INFO:  11700 (0x2db4)
>      ASC/ASCQ:  No Additional Sense Information
> 
> ahc1:SCB 0x6 - timed out
> 
>>>>>>>>>>>>>>>>>>>Dump Card State Begins <<<<<<<<<<<<<<<<<
> 
> ahc1: Dumping Card State while idle, at SEQADDR 0x8
> Card was paused
> ACCUM = 0x99, SINDEX = 0x57, DINDEX = 0x26, ARG_2 = 0x1
> HCNT = 0x0 SCBPTR = 0xf
> SCSISIGI[0x0] ERROR[0x0] SCSIBUSL[0x0] LASTPHASE[0x1]
> SCSISEQ[0x12] SBLKCTL[0x2] SCSIRATE[0x0] SEQCTL[0x10]
> SEQ_FLAGS[0xc0] SSTAT0[0x5] SSTAT1[0xa] SSTAT2[0x0]
> SSTAT3[0x0] SIMODE0[0x0] SIMODE1[0xa4] SXFRCTL0[0x80]
> DFCNTRL[0x0] DFSTATUS[0x2d]
> STACK: 0x0 0x16c 0x19c 0x3
> SCB count = 32
> Kernel NEXTQSCB = 2
> Card NEXTQSCB = 2
> QINFIFO entries:
> Waiting Queue entries:
> Disconnected Queue entries: 15:6
> QOUTFIFO entries:
> Sequencer Free SCB List: 13 0 11 8 7 2 5 6 12 10 9 4 14 1 3
> Sequencer SCB Info:
>   0 SCB_CONTROL[0xe8] SCB_SCSIID[0x67]
> SCB_LUN[0x0] SCB_TAG[0xff]
>   1 SCB_CONTROL[0xe8] SCB_SCSIID[0x67]
> SCB_LUN[0x0] SCB_TAG[0xff]
>   2 SCB_CONTROL[0xe8] SCB_SCSIID[0x67]
> SCB_LUN[0x0] SCB_TAG[0xff]
>   3 SCB_CONTROL[0xe8] SCB_SCSIID[0x67]
> SCB_LUN[0x0] SCB_TAG[0xff]
>   4 SCB_CONTROL[0xe8] SCB_SCSIID[0x67]
> SCB_LUN[0x0] SCB_TAG[0xff]
>   5 SCB_CONTROL[0xe8] SCB_SCSIID[0x67]
> SCB_LUN[0x0] SCB_TAG[0xff]
>   6 SCB_CONTROL[0xe8] SCB_SCSIID[0x67]
> SCB_LUN[0x0] SCB_TAG[0xff]
>   7 SCB_CONTROL[0xe8] SCB_SCSIID[0x67]
> SCB_LUN[0x0] SCB_TAG[0xff]
>   8 SCB_CONTROL[0xe8] SCB_SCSIID[0x67]
> SCB_LUN[0x0] SCB_TAG[0xff]
>   9 SCB_CONTROL[0xe8] SCB_SCSIID[0x67]
> SCB_LUN[0x0] SCB_TAG[0xff]
>  10 SCB_CONTROL[0xe8] SCB_SCSIID[0x67]
> SCB_LUN[0x0] SCB_TAG[0xff]
>  11 SCB_CONTROL[0xe8] SCB_SCSIID[0x67]
> SCB_LUN[0x0] SCB_TAG[0xff]
>  12 SCB_CONTROL[0xe8] SCB_SCSIID[0x67]
> SCB_LUN[0x0] SCB_TAG[0xff]
>  13 SCB_CONTROL[0xe8] SCB_SCSIID[0x67]
> SCB_LUN[0x0] SCB_TAG[0xff]
>  14 SCB_CONTROL[0xe8] SCB_SCSIID[0x67]
> SCB_LUN[0x0] SCB_TAG[0xff]
>  15 SCB_CONTROL[0x44] SCB_SCSIID[0x57]
> SCB_LUN[0x0] SCB_TAG[0x6]
> Pending list:
>   6 SCB_CONTROL[0x40] SCB_SCSIID[0x57]
> SCB_LUN[0x0]
> Kernel Free SCB list: 4 5 0 8 31 7 15 30 9 10 3 14 1 12 13 11 29 28 27
> 26 25 24 23 22 21 20 19 18 17
>  16
> Untagged Q(5): 6
> 
> 
> ahc1:Queuing a BDR SCB
> ahc1:Bus Device Reset Message Sent
> st0(ahc1:0:5:0): ahc1: no longer in timeout, status = 0
> ahc1: Bus Device Reset on A:5. 1 SCBs aborted
> 
> --
> Posted automagically by a mail2news gateway at muc.de e.V.
> Please direct questions, flames, donations, etc. to news-admin@muc.de

i'll try to fire-it-up..
--N