Stephan,
The main thing that I can recommend is to give the new beta release a try. It
features a near-complete rewrite of taper, including all the device-buffering
code. Amongst other things, the tapebufs parameter is deprecated in favor of
a new device_output_buffer_size parameter, which is specified in kilobytes.
If you still have performance problems with the new code, let me know.
Cheers,
--Ian
On Thursday 17 January 2008 14:40:02 Stefan G. Weichinger wrote:
> 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
--
Wiki for Amanda documentation: http://wiki.zmanda.com/
|
