> 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
