Really slow vos dumps to local disks

Norman P. B. Joseph joseph@ctc.com
Tue, 13 Mar 2001 16:30:49 -0500


I just want to trouble the waters here in this pool of AFS experience to see if
this rings a bell with anyone.

In trying to come up with a method for extracting AFS volume information and
munging it into a form palpable to a third-party backup system we have
in-house, I've been playing both with butc's ability to write directly to disk
partitions (via tapeconfig entries), and with dumping individual backup volumes
via 'vos dump' commands into individual files on other local disk partitions.
 In both cases, those partitions would then be backed up as normal UNIX
filesystems via the backup system.  (I'm sure I'm reinventing the wheel here
somewhere, and anyone who's willing to share how they've done
AFS-to-third-party backups will earn my undying gratitude.)

But what puzzles me about both these methods is that they seem to be taking -so
long- to get data from file servers into disk files.  When doing full AFS dumps
to 8mm tapes on these same machines via butc/backup I could fill a ~4GB tape in
less than an hour.  Doing serial "vos dump"s of file server volumes, it took
-all night- to create -one- GB of files on a partition.

AFS version is 3.5 3.56.  Two of the file servers are Sun 220Rs, one is a Sun
250, and one is a Sun 450.  All have their vice partitions on a new
EMC/CLARiiON storage server, where its fiber channel from the host interface to
the drives.  All have both ATM and 100Mb Ethernet interfaces.  Normal AFS
performance from these servers is fine.  I've tried dumping to both local
drives on one of these file server machines and to CLARiiON-mounted drives with
equally slow results.  The machines' CPUs are not being taxed.

I'm not sure where to start looking for problems.  The cell is otherwise
well-behaved, and when using backup/butc to tape I never had an issue.  I'm
tossing this out hoping someone may have seen something similar or be able to
suggest possible avenues for exploration or things to rule out.  Any
suggestions will be gladly received.

Thanks,
--
 Norman Joseph, UNIX Systems Engineer       joseph@ctc.com        IC|XC
 Concurrent Technologies Corporation         814/269.2633         --+--
                                                                  NI|KA
         ftp://ftp.ctc.com/pub/PGP-keys/joseph.asc

  ***  Do a good deed today.  Visit  http://www.thehungersite.com  ***