[8392] in Info-AFS_Redistribution
Re: Backups using commercial products
daemon@ATHENA.MIT.EDU (Mitch Collinsworth)
Wed Jan 3 13:45:39 2001
Date: Wed, 3 Jan 2001 13:19:24 -0500 (EST)
From: Mitch Collinsworth <mitch@ccmr.cornell.edu>
To: Lyle Seaman <lws@spinnakernet.com>
cc: "Neulinger, Nathan R." <nneul@umr.edu>,
Earl R Shannon <Earl_Shannon@ncsu.edu>, info-afs@transarc.com,
"'openafs-devel@openafs.org'" <openafs-devel@openafs.org>
In-Reply-To: <3A535872.DE1E9C5A@spinnakernet.com>
Message-ID: <Pine.LNX.4.10.10101031244050.10684-100000@ruby.ccmr.cornell.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 3 Jan 2001, Lyle Seaman wrote:
> 1. be sure to coordinate the volume access with the vol server so
> that it doesn't get moved or deleted out from under you. This is
> trickier than it sounds.
Just out of curiousity what happens now when a backup is in
progress (backup dump or vos dump of a BK volume) and a vos
move or vos remove is issued? Both of these result in the BK
volume being deleted. Are they held pending completion of
the backup operation first?
> 2. vos dump is slow because
> i. it does a zillion seeks on the disk, one at a time.
> ii. it uses RX at the same time.
>
> If you want to make it faster, you either have to use a different
> local filesystem which keeps data and inodes closer together,
> or you have to queue up all the disk I/O all at once, so the
> disk scheduler can work more efficiently. But then you may be
> hurting fileserver latency.
OK, but how does this explain the results people were reporting
back in August that vos dumps always run at ~3 MB/s indepent of
what hardware is used? Is that because the disk seeks are the
primary bottleneck and seeks take about the same amount of time
regardless of disk type? I guess I'd been assuming it was one
of those big mysteries of RX.
-Mitch
