> Yes, it will do a read of the entire tape. There is a config file option
> called amrecover_do_fsf that if set to true will fsf your tape to the
> correct spot if your drive supports it, which is much faster than a linear
> read.
I do have that set, and the drive finished up in about 1 hour. It obviously
worked, because the full dump takes about 20 hours.
> > My tape only seems to work at about 3 Mbps. The scsi disks it reads from
> > (holding space) and writes to are capable of much more than that (U320,
> raid
> > 5 array).
>
> Best way to figure this out is to post the report that gets emailed
> at the end of your run. It shows dump and tape speeds for each DLE
> and is very informative once you learn what you're looking for.
I'll send one through on the next backup...
> Two possibilities:
> You're bypassing the holding disk and going directly to tape due
> to too small a holdingdisk or your reserve set too high to allow
> fulls to go there.
But even with the holding disk full, shouldn't we expect 6-10Mbps ie network
speed, I have something like 20Gb of holding disk space allocated.
> Contention on the disk, especially if it is also used for other
> tasks, and compounded if inparallel is set very high. RAID5 is often
> not high-performance. I've seen some that do well on a single read
> or write, but seriously degrade with a few simultaneous operations.
> Either way, if the dump can't feed the tape fast enough, the tape
> keeps stopping and repositioning itself, vastly slowing your throughput
> (and wearing out your drive and tape). You might consider increasing
> tapebufs in your config to buffer more data in memory.
The server is idle aside from Amanda, as I run the backup at night.
> Try dd-ing a large file from your disk to /dev/null, /dev/zero to
> your disk, and /dev/zero to a blank tape, and see what the limits of
> your particular hardware are.
Ok, I have increased tapebufs to 80, I'm not really sure how high to
increase it though. I do have plenty of free ram.
I will see tonight how it performs. I don't think it's an amanda issue, I
personally believe it's a tape drive/scsi issue. The drive is an LTO2 drive
u320. Compression is off. Can a faulty terminator cause this speed
degradation?
Oldy write speed is much quicker than read speed! I just double checked,
it's actually raid 1 on the /usr (& amanda dump) partition
SRV# dd if=/dev/zero of=/usr/recover/test ^C5675166+0 records in
5675165+0 records out
2905684480 bytes transferred in 60.056881 secs (48382208 bytes/sec)
SRV# dd if=/usr/recover/test of=/dev/null
5675166+0 records in
5675166+0 records out
2905684992 bytes transferred in 147.353463 secs (19719150 bytes/sec)
SRV# dd if=/usr/recover/test of=/dev/null
5675166+0 records in
5675166+0 records out
2905684992 bytes transferred in 147.716610 secs (19670672 bytes/sec)
SRV# ammt -f /dev/nsa0 rewind
SRV# dd if=/dev/zero of=/dev/nsa0 bs=32k count=10000
10000+0 records in
10000+0 records out
327680000 bytes transferred in 122.037586 secs (2685074 bytes/sec)
Cheers,
Stavros Patiniotis
EscapeNet ~ 08 8292 5200
|
