ADSM-L

Re: Stgpool logical occupation stays above 98%

1998-01-26 10:55:04
Subject: Re: Stgpool logical occupation stays above 98%
From: David Cannon <cannon AT US.IBM DOT COM>
Date: Mon, 26 Jan 1998 10:55:04 -0500
The bullets did not appear in my post, which may by confusing.  I'm resending
this.

> has anybody already checked the "Pct logical" value in the different
> stgpool?
> We runs an MVS 3.1 server, with V3 and V2 clients.

> I noticed for instance a value of 100% which do not decrease, even if
> "Pct migr" = 0 and "Pct util" =40%.

> According to the doc, the logical occupation should be less than 100%
> and also less than physical occupation. If not, that would mean our
> aggregates are all full!

> I would appreciate your comments...

From the information you have given, there does not appear to be a problem with
the Pct Logical value.  You also questioned in a separate note whether this
high value is caused by the reclamation problem that was reported on Friday.
The answer is no.

The %Logical field was added to the detailed output of the Query Stgpool
command in Version 3 servers.  A high value is desirable and means that a small
fraction of the total occupancy in your storage pool is vacant space caused by
logical files that have been deleted from within aggregates.  There are various
reasons why this value may appear to remain high, including

* Most of the storage pool occupancy is attributed to non-aggregated files that
were stored using a pre-Version 3 server

* You are not getting much aggregation because client files are very large or
because your settings from TXNBYTELIMIT or TXNGROUPMAX are too small

* If logical files within aggregates are closely related, they may all tend to
expire at the same time so entire aggregates get deleted rather than leaving
aggregates with vacant space

* Reclamation of sequential storage pools removes vacant space within aggregates
and raises the %Logical value for that pool

* From your values of PctUtil and PctMigr, I assume that you have a disk storage
pool with caching turned and whose data gets migrated soon after it is stored.
Cached files do not count toward the occupancy of a pool, since they are
subject to replacement at any time.  Thus the total occupancy of your disk pool
is near 0 and the aggregates that are stored in the disk pool have very few
vacancies because logical files have not yet been deleted.  This results in a
very high value for %Logical.

Dave Cannon
ADSM Development


<Prev in Thread] Current Thread [Next in Thread>