On Wed, 2004-06-02 at 14:12, Gene Heskett wrote:

> Any current ide drive can do 30+ Mb/sec if left 
> alone by other tasks, often quite a ways on the + side.

Is that just a burst out of the cache, or can they read dis-contiguous
files, seek around to other files, wait for latency, and write all at
the same time that fast? Or even half that fast? If so, and if Linux and
Intel's IDE controllers lose another 25% moving bits around, it'd still
be comfortably faster than the tape drive. I think I may have something
horribly misconfigured.

> If you are not using spindle numbers in your disklist, maybe it would 
> help to prevent thrashing of seeks all over the place because more 
> than one dumper is attacking the drive simultainiously.

I am. It helped a lot.

> This might mean that the tape would stop and do a bit of shoeshining 
> in between files, but a given file should be able to be 'poured down 
> the pipe' non-stop.

That'd be one 'buzz-squinch-buzz' per dump file. That's a possibility.
I'll look into it. Also an argument against thousands of partitions.

> There is also an algorythm string in amanda.conf that adjusts the 
> dumporders a bit, I have mine set to to the largest dump first, so 
> that once its done, there is a good chance the rest of the thing is 
> already in the holding disk and I get the drives maximum speed once 
> it actually starts.

That I didn't know about at all. I'll go find it.

> In this case, it seems he needs two disks assigned as holding disks, 
> with the hope that amanda would write to one, then the other, 
> alternating such that the one being written was not being read by a 
> taper at the same time.

Now that's silly :-) Amanda's creating big, contiguous files designed to
stream a tape drive. Disk drives are supposed to be vastly faster than
the tape. From what you said earlier, that's where I think I need to
focus attention.

There and maybe just a little on reducing SCSI snobbery :-) Very
informative. Thanks.

-- 
Glenn English <ghe AT slsware DOT com>