อ้างจาก Technote ของ IBM

“query volume” shows estimated capacity value less than expected value

Technote (FAQ)

Question

For volumes in status full, “query volume” shows the estimated capacity less than what is really stored on the volume

Answer

The QUERY VOLUME command does not always display a expected volume capacity when the
volume has reached end-of volume (EOV). When a volume is in status full, the estimated
capacity always displays the real capacity of the volume, i.e. the total number of bytes being stored on the volume in general. This value of the real capacity may not match the value of the estimated capacity. The value of the real capacity could be smaller than the value of the estimated capacity..

Here is an example from a WORM LTO3 tape. This WORM LTO3 tape volume was brand new.
The LTO3 compressed mode was used for backup data. When this volume was full, the Estimated Capacity showed that the volume capacity was 91.7G in this example. However, when the volume was empty, the Estimated Capacity was 400G. So the real capacity is smaller than the previous estimated capacity.

The output from Tivoli Storage Manager server console for LTO3 WORM tape:

 Volume Name Storage   Device     Estimated Scaled   Pct   Volume  Access  
             Pool Name Class Name Capacity  Capacity Util  Status        
                                                           Applied 
 ----------- --------- ---------- --------- -------- ----- ------- ----------
 VOL001L3    WORMPOOL  WORMTAPE   91.7 G             100.0 Full    Read/Write
 
 
 

To get the full estimated capacity, you can define a storage pool with the option
dataformat=nonblock. For more information about the dataformat parameter see the
Tivoli Storage Manager server Administrator Reference.

This issue is also related to the Tivoli Storage Manager server option TXNGroupmax.

The Tivoli Storage Manager server write a segment each time to the volume.
A segment is usually a aggregate bitfile which contains up to number of “TXNGroupmax”
files. If the size of a segment (aggregate bitfile) is smaller than the block size 256K,
there will be gap in the volume because it wrote 256K each time.
If the size of a segment greater than 256K, it will write multiple times with 256K
each time until the whole segment wrote to the volume, so, most time, the last write
for a segment will have gap because the segment size is not likely to be integral
multiple of 256K. But most time, the size of a segment is much bigger than 256K,
so the percentage of wasted space can be very small.

The gap is introduced when backup or archive from the client.
There is no way to remove the current gap unless the files get expired.

You can increase TXNGroupmax to prevent further gap.
But notice that use a too lager value of TXNGroupmax could cause performance issue.
For more information about the TXNGroupmax server option see the Tivoli Storage Manager
server Administrator Reference.
You can use the following way to calculate how you should change TXNGroupmax to.

Example:
The current TXNGroupmax is A, the capacity of volume is B,
the data can actually wrote to the volume is C.
The new TXNGroupmax can be calculated as follow: A * B / C.
For example, if the current TXNGroupmax is 256, the capacity of LTO3 tape is 400G,
the data can actually wrote to the tape is 91.7G.
You can change the TXNGroupmax to 256 * 400 / 91.7 = 1116

The root cause is if you have many very small files and we are writing many small segments
(smaller than 256K) to the volume, and that caused space gap in the volume.
Increasing TXNGroupmax can prevent this kind of gap.

Example with FILE type volume to see how it works .
After increasing the TXNGroupmax, the problem can be resolved.

First test:
Define two FILE type devclass FILEDEV and FILEDEV2 which have capacity 200M and 40M respectively.
Backup about 100000 files, each file is smaller than 1K.
The TXNGroupmax is 256. After backup stgpool, we can see the volume 00000011.BFS has
estimated capacity of 23.1M which smaller than the devclass’ capacity.
23.1M is the actually data wrote to the volume.

query volume

 Volume Name          Storage     Device      Estimated     Pct    Volume
                      Pool Name   Class Name   Capacity    Util    Status
 -------------------- ----------- ----------  ---------   -----   --------
 D:\TSM\0000000C.BFS  FILEPOOL    FILEDEV       200.0 M    20.3   Filling
 D:\TSM\00000011.BFS  COPYPOOL    FILEDEV2       23.1 M   100.0     Full
 D:\TSM\00000012.BFS  COPYPOOL    FILEDEV2       40.0 M    43.8   Filling
 
 

Second test:

Backup more files than first test, define the second devclass FILEDEV3 has capacity of 50M .
The TXNGroupmax is 440 this time. After backup stgpool, we can see the volume 0000002D.BFS
has estimated capacity of 49.6M which very close to 50M.

query volume

 Volume Name          Storage     Device      Estimated     Pct    Volume
                      Pool Name   Class Name   Capacity    Util    Status
 -------------------- ----------- ----------  ---------   -----   --------
 D:\TSM\00000027.BFS  FILEPOOL    FILEDEV       200.0 M    28.9   Filling
 D:\TSM\0000002C.BFS  FILEPOOL    FILEDEV       200.0 M     0.6   Filling
 D:\TSM\0000002D.BFS  COPYPOOL    FILEDEV3       49.6 M   100.0     Full
 D:\TSM\0000002E.BFS  COPYPOOL    FILEDEV3       50.0 M    19.0   Filling