ADSM-L

Re: Space Problems

2000-04-10 08:33:22
Subject: Re: Space Problems
From: "Cook, Dwight E" <cookde AT BP DOT COM>
Date: Mon, 10 Apr 2000 07:33:22 -0500
Here is the poop on that...
If cache is on in the disk storage pool, this condition is worse than if it
is off...
prior to a client sending a file, the space (same as allocated on client) is
allocated on the adsm server's disk storage pool...
if cached files are required to be removed they are...
now I can also tell you have compression yes and compressalways yes  (set
compressalways no and that will fix the problem)
So the client is going to send a real big binary type file (say something
that is already compressed)
Space is cleared on the adsm server's disk storage pool... (cached files are
cleared to obtain the space)
File is sent from the client but since it is already compressed the size of
the file grows (cause of the header poop of adsm compression)
NO ADDITIONAL CACHED FILES WILL BE CLEARED TO PROVIDE ADDITIONAL SPACE on
the adsm server's storage pool...
generally you won't see t his if you have cache turned off
and you shouldn't ever see this going straight to tape
and you shouldn't see this if you set you client to compressalways no

later,
        Dwight

> ----------
> From:         Lindsay Morris[SMTP:lmorris AT OPENMIC DOT COM]
> Reply To:     ADSM: Dist Stor Manager
> Sent:         Monday, April 10, 2000 3:06 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Space Problems
>
> I usually see this when
> 1. client compression is turned on, and
> 2. client has large or many compressed files.
>
> TSM compression increases the size of a zip or tiff or ... compressed
> file, and this fools the server.
>
> can you turn off compression?
>
> "Burns, Kye" wrote:
> >
> > Hello *SM'ers,
> > I queried the activity log and came up with the error below. Our SSA
> drawers
> > for the hard disks were recently reconfigured which lowered our Database
> > Utilization to a lower level around 67% from a prior level of 83%.
> >
> > 04/09/00 00:18:48 ANR0406I Session 11460 started for node CWS1 (AIX)
> (Tcp/Ip
> > 172.29.3.50(65076)).
> > 04/09/00 04:18:45 ANR0534W Transaction failed for session 11460 for node
> > CWS1 (AIX) - size estimate exceeded and server is unable to obtain
> > additional space in storage pool AIX_DISK.
> >
> > Here is the Error message for AIX_DISK issue:
> > ANR0534W Transaction failed for session session number for node node
> name
> > (client platform) - size estimate exceeded and server is unable to
> obtain
> > additional space in storage pool pool name.
> > Explanation: The server ends a database update transaction for the
> specified
> > session because the size estimate provided by the client is too small.
> The
> > server has attempted to obtain additional space in the indicated storage
> > pool, but was unable to do so.
> > System Action: The specified session is ended and server operation
> > continues.
> > User Response: This message may indicate that there is no additional
> space
> > in pool name. If that is the case, an authorized administrator can issue
> the
> > DEFINE VOLUME command to add storage this pool.
> > If pool name is a random access storage pool with caching enabled, it is
> > also possible that additional space can be made available in this
> storage
> > pool by eliminating cached files. When the server allocates space based
> on
> > the size estimate provided by the client, it frees space occupied by
> cached
> > files if this space is needed to obtain the estimated space. However, if
> the
> > server later determines that the file size estimate was too low, it
> attempts
> > to obtain additional space that is not utilized, but does not delete
> cached
> > files to do so. If you believe that pool name contains additional space
> > occupied by cached files, you can turn caching off. To free space that
> is
> > already occupied by cached files, use the MOVE DATA command for the
> volumes
> > in pool name.
> >
> > In the sequential access storage pool STK_AIX_TAPE there are four tapes
> in
> > this pool which are filling, however the rest of the 10 tapes in this
> > secondary pool show a full status. This is an observation on my part and
> HSM
> > (Hierarchy Storage Management) will look to the next stgpool to store
> data.
> > No caching is enabled. Any suggestions? From Kye Burns.
> >
> >  <<...>>
>
> --
> Mr. Lindsay Morris
> Certified: AIX,ADSM, TSM, HACMP,SP
> Gresham Enterprise Storage
> lmorris AT openmic DOT com
> 606-253-8000
>
<Prev in Thread] Current Thread [Next in Thread>