Greets, amanda-users,

as you may have read already I bought a used HP library with a
DLT8000-drive in it.

library: HP C7201NB
SCSI storage controller: Adaptec AIC-7892B U160/m (rev 02)

The host is an old P3 866 and runs an up-to-date gentoo linux, slightly
patched amanda 2.5.2_p1 on it.

I am trying to get it running OK here and as I get only rather low
throughput to tape I started to research things, browse the archives ...

I found a mail from Joshua saying:

> Amanda doesn't 'tar' directly to tape, so it's not tar's blocksize
> you need to change.  Amanda does its writing to tape with a default
> blocksize of 32KiB.  To change that, you'll need to recompile amanda
> and specify the --with-maxtapeblocksize option to configure.  With my
> LTO3 drive, I compile amanda with --with-maxtapeblocksize=2048.
> 
> After recompiling amanda, you can change the blocksize in the
> tapetype. Mine says "blocksize 2048", for a 2MiB blocksize.  My
> backups generally tape at >60MiB/s.

Recompiled amanda, edited tapetype and tapebufs:

tapebufs 30
tapetype DLT2
define tapetype DLT2 {
    comment "sgw: DLT8000 in Surestore C7201NB, DLTIV-Tapes"
    length 36000 mbytes
    filemark 32 kbytes
    # blocksize added 2008-01-16, sgw
    blocksize 2048
    speed 2879 kps
}


I know, the speed is wrong ... I just copied that tapetype ...
But afaik that parameter isn't used yet, is it?

--

Browsed quantum-pdfs, edited stinit.def accordingly (executed stinit
...), used /dev/nst0m (mode 4) in amanda.conf


----stinit.def

# QUANTUM DLT8000
manufacturer=QUANTUM model="DLT8000" {

# Global Keywords and Values
drive-buffering=1
#scsi2logical=1
no-wait=0
buffering=0
async-writes=0
read-ahead=1
two-fms=0
auto-lock=0
fast-eom=1
can-bsr=1
noblklimits=0
# can-partitions=0

timeout=3600
long-timeout=14400
can-partitions=0
mode1 blocksize=0 density=0x41 compression=1 # DLT8000 density,
compression on
mode2 blocksize=0 density=0x41 compression=0 # DLT8000 density,
compression off
mode3 blocksize=0 density=0x1B compression=1 # DLT7000 density,
compression on
mode4 blocksize=0 density=0x1B compression=0 # DLT7000 density,
compression off
}

----end stinit.def


I see very long times for amlabel (example-time taken with another tape
in drive when issuing that command, so the robot does unload the other
tape first):

$ time amlabel -f dds OLD-08 slot 5
labeling tape in slot 5 (/dev/nst0m):
rewinding, reading label, not an amanda tape (Input/output error)
rewinding, writing label OLD-08, checking label, done.

real    18m34.751s
user    0m0.970s
sys     0m1.320s


I have no comparison but it seems very slow to me.


And in my REPORT I see:

----->

NOTES:
  taper: attach_buffers: (30 tapebufs: 62919016 bytes) Invalid argument
  taper: attach_buffers: (29 tapebufs: 60821852 bytes) Invalid argument
  taper: attach_buffers: (28 tapebufs: 58724688 bytes) Invalid argument
  taper: attach_buffers: (27 tapebufs: 56627524 bytes) Invalid argument
  taper: attach_buffers: (26 tapebufs: 54530360 bytes) Invalid argument
  taper: attach_buffers: (25 tapebufs: 52433196 bytes) Invalid argument
  taper: attach_buffers: (24 tapebufs: 50336032 bytes) Invalid argument
  taper: attach_buffers: (23 tapebufs: 48238868 bytes) Invalid argument
  taper: attach_buffers: (22 tapebufs: 46141704 bytes) Invalid argument
  taper: attach_buffers: (21 tapebufs: 44044540 bytes) Invalid argument
  taper: attach_buffers: (20 tapebufs: 41947376 bytes) Invalid argument
  taper: attach_buffers: (19 tapebufs: 39850212 bytes) Invalid argument
  taper: attach_buffers: (18 tapebufs: 37753048 bytes) Invalid argument
  taper: attach_buffers: (17 tapebufs: 35655884 bytes) Invalid argument
  taper: attach_buffers: (16 tapebufs: 33558720 bytes) Invalid argument
  taper: tape OLD-07 kb 28241920 fm 28 writing file: No space left on device
  driver: Taper  error: "[writing file: No space left on device]"
  driver: going into degraded mode because of taper component error.

---

As far as I understand my Tape buffer would be

tapebufs x blocksize  ==  30 x 2048k ---> 60 MB

correct?

Too large?

--

My report also gives me

"Avg Tp Write Rate (k/s)  2496.1     2490.6     6474.1"

I assume this should be faster ...


--

I don't have a cleaning tape here right now, and the drive wants
cleaning ... maybe this will solve all my issues in the end (I will get
the new tape on tuesday).

Ah, yes, I also get these:

# dmesg
st0: Sense Key : 0x3 [current]
Info fld=0x800000
st0: <<vendor>> ASC=0x80 ASCQ=0x1ASC=0x80 ASCQ=0x1

;)


Does anyone see any big mistake in my approach?
Something I could change or improve?

I start another amdump now for further testing.

Thanks for any help on this,
Stefan