Well, I don't think you're EVER going to get the same performance for
AFS dumps that you get from dump on a UNIX file system - nonetheless,
we are using DLT's here on our Solaris 2 servers. If you wait for AFS 3.4
you'll find that it has a parameter for setting block file size on
the dump devices - this does a LOT for the performance of Exabyte or
DLT drives. I don't see any way to do anything about it without having
AFS 3.4, though.
Steve Hanson - FERMILAB, Batavia, Il.
[EMAIL PROTECTED] or [EMAIL PROTECTED]
On Fri, 18 Aug 1995, Steve Mattson wrote:
> Hi,
>
> Some people here have been evaluating a DLT 2000 drive for doing standard
> unix dumps. As compared to an Exabyte 8505 they're getting quite a
> performance increase. They can achieve ~60 MB per minute sustained
> transfer rates to the drive. The drive is rated at a max of 1.25 MB/sec
> and so a 1 MB/sec transfer rate like this seems appropriate. They had
> gotten some lower rates at first and then found that by bumping up the
> block size option to dump they could achieve the above rates.
>
> On the same machine, using the same two drives, I can't get anywhere
> near that performance using afs backup/butc. I'm seeing around 10 MB
> per minute on both the DLT 2000 and on the Exabyte 8505. I can't see
> any option that would let me bump up the block size in a similar manner,
> if indeed that's what I need to be able to do to get better sustained rates.
> I *can* hear the drive starting and stopping all the time when the afs
> backup is running, so I know it's not streaming like it should be.
>
> I saw a posting last January that mentioned changing some parameters
> in the kernel configuration under Solaris 2.4, but not all of those
> options seemed to map to older SunOS 4.1.3 defines. Does anyone have
> any good experiences getting these drives to perform at rated speeds
> and wisdom that they could pass along? The machine in question and
> the servers I'm dumping from are on an fddi ring and given that the
> unix dumps can get higher rates than I'm seeing it doesn't seem to be
> strictly a hardware issue.
>
> Thanks,
>
> Steve Mattson
> University of Michigan - CAEN
>
