ADSM-L

Re: How to avoid sending files larger than the STGPOOL MAXSIZE ?

2001-01-31 10:09:53
Subject: Re: How to avoid sending files larger than the STGPOOL MAXSIZE ?
From: Ole Holm Nielsen <Ole.H.Nielsen AT FYSIK.DTU DOT DK>
Date: Wed, 31 Jan 2001 16:11:33 +0100
rbs AT bu DOT edu wrote:
> >However, this didn't solve the problem.  One 120 MB file had 35%
> >sent to the server (with STGPOOL MAXSIZE=50m), before the expected
> >warning came:
> >   ANS1310E Object too large for server limits
>
> Ole - How annoying!  On the surface of it, this doesn't make much sense.
>
> Does your backup storage consist of a single storage pool, or a
> hierarchy in which Maxsize is specified on the first one?  I'm
> speculating a case in which there is a 2-level hierarchy, the first
> level has the Maxsize, and the second is just tape...but of limited
> physical capacity, and the space exhaustion is being attributed to
> the maxsize rather than "server out of data storage space".  That's
> just a speculation, and I don't think that much of it.  The error
> message should involve simple rejection by size, not a physical
> attempt to accept the data.  (See APAR IY00820, which explains some
> ramifications of ADSM storage computations.)  It may be that there
> is a client defect where it is failing to correctly determine the
> size of the file beforehand, but I don't see an APAR for that (which
> doesn't mean that there isn't one).  You could try the 3.7 version of
> the client: it would install into a separate directory from your 3.1
> client, but watch out for /usr/bin/dsmc being pointed to the new
> client version.

I followed your advice and installed client version 4.1.2 on a node with
no previous ADSM client.  It works nicely, like the 3.1.0.8 client.
However, the files exceeding STGPOOL MAXSIZE are still transferred
over the network, until nearing the MAXSIZE limit !!  The client is
running Compaq Tru64 UNIX v4.0F.

My storage pools are:  Primary backup pool is a 10 GB disk, the
secondary pool is an (old) Quantum DLT4700 jukebox (7*20GB + compression).
Both pools have STGPOOL MAXSIZE=50m !  I'm pretty sure that there
isn't any capacity problem at all in any of the two pools.
I forced data-compression off in the server.

The observed behavior of the ADSM v3.1.2.90 server doesn't make much
sense:  It's very late in discovering that the client is doing a
transfer of a file, which is going to exceed all available storagepools'
MAXSIZE limits.  This means a huge slowdown of the backups.
Is my problem due to lack of configuration of the ADSM server,
or is it a bug in ADSM that I just have to live with ?

I wish that someone could verify that the newer Tivoli ADSM servers
wouldn't have this problem...  If so, I'd order an upgrade :-)

Ole Holm Nielsen
Department of Physics, Technical University of Denmark,
Building 307, DK-2800 Lyngby, Denmark
<Prev in Thread] Current Thread [Next in Thread>