On Sat, Jan 11, 2003 at 10:21:11PM +0100, Toni Mueller wrote:
>
> Hi,
>
> On Wed, Apr 17, 2002 at 10:01:11AM +0200, Johannes Niess wrote:
> > Jon LaBadie <jon AT jgcomp DOT com> writes:
> > > On Tue, Apr 16, 2002 at 10:24:17PM -0500, Dan Debertin wrote:
> > > > One of my client hosts has a drive that is larger than my holding disk
> > > > -- drive is 18G, holdingdisk is only 4G. No, I can't swap them, and
> > > > no, I'd rather not buy a bigger disk right now.
> > > >
> > > > I would have thought that Amanda would dump the client to the
> > > > holdingdisk in 1G chunks (isn't that what the "chunksize" directive is
> > > > for?), as it does the other clients, and then gradually flush those to
> > > > tape, in order to keep the drive streaming.
>
> that's what I learned today, too (after getting a bigger & faster
> tape) :-(
>
> > > > But it's not; it uses the holdingdisk for the other clients, and
> > > > dumps straight to tape with the large one.
>
> The same goes even if the disk(s) are all local.
>
> > > I don't believe so. I think the entire fs is dumped to the holding disk
> > > before anything gets sent to tape. If the holding disk is not large
> > > enough to hold the fs, it must go directly to tape.
>
> There should be a way around this, otherwise the holding disk idea is
> only half as powerful as can be. A modern tape drive eats data faster
> than reasonable disks can deliver directly from the file system (in my
> case: a DLT drive, and a 36G disk which I arranged to be idle during
> my tests).
In that case, except for the parallelism, going directly to tape is a fine
choice.
>
> > > The chunksize parameter is generally used to work around the single
> > > file size limit that some os's have.
>
> That's "underused. How hard would it be to fix that?
I suspect very substantial. Much of amanda's use of the holding disk assumes
a complete backup exists there.
> > On the source level maybe an insane increase to the buffer
> > between the two taper processes could help. That leads to heavy RAM
> > and OS swap space usage on the tape server.
>
> That I don't understand. Can you please point to a specific place
> in the source where I should be looking? Currently I'm using the
> Debian package of 2.4.3, but could (and would) tweak the source
> if that would be helpful.
>
> > Or you could switch from dump to tar and backup subdirectories that
> > each are less than 4 GB.
>
> Tar is even worse since it hammers the disk on end just to figure out
> the prospective backup size, and then goes all over it again to collect
> the data, -and- is way, way slower than dump. I don't know if not all
> to-be supported platforms have "du", but that is much faster than tar,
> and could (?) be well enough for producing an estimate. When I made
> backups without Amanda, the speed difference was about a factor of 10...
There have been proposals and workarounds to substitute your own estimate
procedure for calcsize. I don't have them at hand however.
--
Jon H. LaBadie jon AT jgcomp DOT com
JG Computing
4455 Province Line Road (609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
|
