TSM 5.1, LTO 1. Tape should be full, but TSM is still using it an not pickup up another scratch vol

[wjoyce]

Hi, TSM 5.1, LTO 1. The tape CACPS001 should be full, but TSM is still using it and not pickup up another scratch volume. LTO 1 is 100/200GB right?



q vol returns

CACPS001 UNIX_STORA- LTO_DEVIC- 488,089.1 100.0 Filling

GE_POOL E_CLASS



q vol cacps001 f=d returns... how can this be?



Volume Name: CACPS001

Storage Pool Name: UNIX_STORAGE_POOL

Device Class Name: LTO_DEVICE_CLASS

Estimated Capacity (MB): 488,089.1

Pct Util: 100.0

Volume Status: Filling

Access: Read/Write

Pct. Reclaimable Space: 0.0

Scratch Volume?: Yes

In Error State?: No

Number of Writable Sides: 1

Number of Times Mounted: 46

Write Pass Number: 1

Approx. Date Last Written: 12/03/03 00:19:10

Approx. Date Last Read: 11/18/03 08:49:10

Date Became Pending:

Number of Write Errors: 0

Number of Read Errors: 0

Volume Location:

Last Update by (administrator):

Last Update Date/Time: 11/04/03 10:26:20





Tivoli Storage Manager

Command Line Administrative Interface - Version 5, Release 1, Level 5.0

(C) Copyright IBM Corporation 1990, 2002 All Rights Reserved.



Enter your user id: admin



Enter your password:



Session established with server TSM_SERVER_HOSTA: AIX-RS/6000

Server Version 5, Release 1, Level 5.0

Server date/time: 12/03/03 11:21:46 Last access: 11/30/03 23:44:16





tsm: TSM_SERVER_HOSTA>q files



Node Name Filespace FSID Platform Filespace Is Files- Capacity Pct

Name Type pace (MB) Util

Unicode?

--------------- ----------- ---- -------- --------- --------- -------- -----

HOSTA /home 41 AIX JFS No 128.0 12.3

HOSTA / 42 AIX JFS No 256.0 11.8

HOSTA /usr 43 AIX JFS No 4,096.0 36.4

HOSTA /var 44 AIX JFS No 512.0 8.6

HOSTA /opt 45 AIX JFS No 64.0 57.6

HOSTA /oracle 46 AIX JFS No 4,096.0 87.1

HOSTA /oracle/ad- 47 AIX JFS No 512.0 6.5

min

HOSTA /oracle/lo- 48 AIX JFS No 2,048.0 68.0

gs

HOSTA /banner 49 AIX JFS No 4,096.0 63.0

HOSTA /banproc 50 AIX JFS No 512.0 33.7

HOSTA /bantest 51 AIX JFS No 3,328.0 54.1

HOSTA /bantemp 52 AIX JFS No 1,024.0 6.9

HOSTA /proddb/or- 53 AIX JFS No 13,824.0 92.2

adata

HOSTA /proddb/ar- 54 AIX JFS No 512.0 40.1

chives

HOSTA /testdb/or- 55 AIX JFS No 13,312.0 94.1

adata

HOSTA /testdb/ar- 56 AIX JFS No 256.0 3.2

chives

HOSTA /users 57 AIX JFS No 1,024.0 52.3

HOSTA /usr/tivol- 58 AIX JFS No 1,024.0 64.5

i/tsm

HOSTA /orahb 59 AIX JFS No 17,376.0 44.5



tsm: TSM_SERVER_HOSTA>q libv



Library Name Volume Name Status Owner Last Use Home Element

------------ ----------- ---------- ---------- --------- ------------

LTO3581_A CACPS001 Private Data 1

LTO3581_A CACPS002 Scratch 2

LTO3581_A CACPS003 Scratch 3

LTO3581_A CACPS004 Scratch 4

LTO3581_A CACPS005 Scratch 5

LTO3581_A CACPS006 Scratch 6

LTO3581_A CACPS007 Scratch 7



tsm: TSM_SERVER_HOSTA>q vol



Volume Name Storage Device Estimated Pct Volume

Pool Name Class Name Capacity Util Status

(MB)

------------------------ ----------- ---------- --------- ----- --------

/usr/tivoli/tsm/server/- ARCHIVEPOOL DISK 8.0 0.0 On-Line

bin/archive.dsm

/usr/tivoli/tsm/server/- BACKUPPOOL DISK 8.0 0.0 On-Line

bin/backup.dsm

/usr/tivoli/tsm/server/- SPACEMGPOOL DISK 8.0 0.0 On-Line

bin/spcmgmt.dsm

CACPS001 UNIX_STORA- LTO_DEVIC- 488,089.1 100.0 Filling

GE_POOL E_CLASS



tsm: TSM_SERVER_HOSTA>q vol cacps001



Volume Name Storage Device Estimated Pct Volume

Pool Name Class Name Capacity Util Status

(MB)

------------------------ ----------- ---------- --------- ----- --------

CACPS001 UNIX_STORA- LTO_DEVIC- 488,089.1 100.0 Filling

GE_POOL E_CLASS



tsm: TSM_SERVER_HOSTA>q vol cacps001 f=d



Volume Name: CACPS001

Storage Pool Name: UNIX_STORAGE_POOL

Device Class Name: LTO_DEVICE_CLASS

Estimated Capacity (MB): 488,089.1

Pct Util: 100.0

Volume Status: Filling

Access: Read/Write

Pct. Reclaimable Space: 0.0

Scratch Volume?: Yes

In Error State?: No

Number of Writable Sides: 1

Number of Times Mounted: 46

Write Pass Number: 1

Approx. Date Last Written: 12/03/03 00:19:10

Approx. Date Last Read: 11/18/03 08:49:10

Date Became Pending:

Number of Write Errors: 0

Number of Read Errors: 0

Volume Location:

Last Update by (administrator):

Last Update Date/Time: 11/04/03 10:26:20

 

[neil_b]

compression? :-o

 

[nasrm]

I see this a lot in my library. You can't really trust the capacity field in that query. try reclaiming that storage pool. I am not really sure how to reclaim that particular tape. if any one does please reply.



Sometimes you get a tape with an estimated capacity of 198,992.0 with pct_util at 0.2 .



Hope that kinda helps

 

[heada]

I see this kind of activity on my 3590 tapes all the time. If when you defined the devclass, you set the "est size" of each tape. It looks like you have that set to something less then 488GB. (I'd guess 200GB) The key is this is only an est size. The actual size may be more or less. If you write data to that tape that is very compression friendly, then you'll get more on that tape then you would if you write already compressed data. I can fit 1.3TB of data from one of my Oracle databases on 6 tapes of 60GB each. It all depends on how well it compresses.



The reason it says 100% full but yet still in filling status is because you haven't totally filled that tape but it is past the est size. You can have full tapes having only 30GB on them and tapes in filling status with 500GB on them. TSM will continue to update the est size on that tape past the devclass est size until it is totally full (and it switches from filling to full)



If you would like to reclaim JUST that one tape (as someone suggested below) perform a move data on it. This will cause TSM to move all data from that tape to a new one and mark the origianl scratch again. If there is reclaimable space, it will remove that space.



TSM> move data CACPS001



-Aaron

 

[wjoyce]

Thanks for all that have replied.



Neil_b, I realize that compress is involved, but I exptected no more than the 200GB compressed that LTO 1 claims.



As of today, I am still on the first libv. The larges fs backed up actually is some oracle data files like in your case heada.



Would the 'move data' command simply make another libv identical to the original libv?

I don't need that particular libv for any reason, so I guess everything is normal.



However, is there a query that shows the compressed ratio or size of data on the tape?



Thanks again for the insight.



q libv



Library Name Volume Name Status Owner Last Use Home Element

------------ ----------- ---------- ---------- --------- ------------

LTO3581_A CACPS001 Private Data 1

LTO3581_A CACPS002 Scratch 2

LTO3581_A CACPS003 Scratch 3

LTO3581_A CACPS004 Scratch 4

LTO3581_A CACPS005 Scratch 5

LTO3581_A CACPS006 Scratch 6

LTO3581_A CACPS007 Scratch 7



tsm: TSM_SERVER_HOSTA>q vol cacps001 f=d



Volume Name: CACPS001

Storage Pool Name: UNIX_STORAGE_POOL

Device Class Name: LTO_DEVICE_CLASS

Estimated Capacity (MB): 560,774.2

Pct Util: 100.0

Volume Status: Filling

Access: Read/Write

Pct. Reclaimable Space: 0.0

Scratch Volume?: Yes

In Error State?: No

Number of Writable Sides: 1

Number of Times Mounted: 56

Write Pass Number: 1

Approx. Date Last Written: 12/09/03 00:09:49

Approx. Date Last Read: 11/18/03 08:49:10

Date Became Pending:

Number of Write Errors: 0

Number of Read Errors: 0

Volume Location:

Last Update by (administrator):

Last Update Date/Time: 11/04/03 10:26:20



>q occu



Node Name Type Filespace FSID Storage Number of Physical Logical

Name Pool Name Files Space Space

Occupied Occupied

(MB) (MB)

---------- ---- ---------- ----- ---------- --------- --------- ---------

HOSTA Bkup /home 41 UNIX_STOR- 654 26.20 26.20

AGE_POOL

HOSTA Bkup / 42 UNIX_STOR- 2,445 42.03 42.03

AGE_POOL

HOSTA Bkup /usr 43 UNIX_STOR- 30,942 1,686.29 1,686.29

AGE_POOL

HOSTA Bkup /var 44 UNIX_STOR- 3,367 247.19 247.19

AGE_POOL

HOSTA Bkup /opt 45 UNIX_STOR- 1,095 34.16 34.16

AGE_POOL

HOSTA Bkup /oracle 46 UNIX_STOR- 14,590 3,550.65 3,550.65

AGE_POOL

HOSTA Bkup /oracle/a- 47 UNIX_STOR- 148 286.57 286.57

dmin AGE_POOL

HOSTA Bkup /oracle/l- 48 UNIX_STOR- 470 38,933.83 38,933.83

ogs AGE_POOL

HOSTA Bkup /banner 49 UNIX_STOR- 24,817 3,800.79 3,800.79

AGE_POOL

HOSTA Bkup /banproc 50 UNIX_STOR- 11,854 304.30 304.30

AGE_POOL

HOSTA Bkup /bantest 51 UNIX_STOR- 20,040 3,054.84 3,054.84

AGE_POOL

HOSTA Bkup /bantemp 52 UNIX_STOR- 175 37.39 37.39

AGE_POOL

HOSTA Bkup /proddb/o- 53 UNIX_STOR- 993 473,971.5 473,971.5

radata AGE_POOL 8 8

HOSTA Bkup /proddb/a- 54 UNIX_STOR- 848 2,540.90 2,540.90

rchives AGE_POOL

HOSTA Bkup /testdb/o- 55 UNIX_STOR- 54 24,207.68 24,207.68

radata AGE_POOL

HOSTA Bkup /users 57 UNIX_STOR- 9,969 523.32 523.32

AGE_POOL

HOSTA Bkup /usr/tivo- 58 UNIX_STOR- 851 341.70 341.70

li/tsm AGE_POOL

HOSTA Bkup /orahb 59 UNIX_STOR- 31 7,184.75 7,184.75

AGE_POOL

 

[heada]

The move data option will just write a new tape like the old one because your volume is 0% reclaimable.



I would talk with the Oracle DBA and find out how full the Oracle database is. If this database is empty, you can compress a 2GB file down to 10MB but TSM will report that as 2GB.



I don't have any LTO drives so I don't know if you can query the drive to see what compression settings it has but you should be able to look at the devclass and see how that class is setup within TSM to write to the drive. With a 3590 drive, you can define the type as 3590E or 3590E-C (with compression) or you can just have the drive use compression. Is there something similar for LTO?



If possible, try to fill that tape. I'm sure someone in the group can give you a command to redirect /dev/zero to a file (maybe via dd?) to create a large file (maybe about 10GB) that will not compress very well (since it is almost purely random). Assuming 200GB per tape, you would need to back it up 20 times (absolute or an archive) before it fills a tape. Just an idea if you want to find out if it's your data or your tape.



-Aaron

 

[AndyRH]

I would not worry about your tape drives getting good compression, it happens. At some point the tape will reach the end and TSM will go on to the next tape. I have included some extreme examples from one of my servers. Note that my native capacity is 40gb. (3590-E)

296gb on a 40gb tape! That one is my hero.

35gb on a 40gb tape? Pre-compressed data. (We use TSM compression at the server for SQL and Exchange)



Andy



Volume Name Storage Device Estimated Pct Volume

Pool Name Class Name Capacity Util Status

(MB)

------------------------ ----------- ---------- --------- ----- --------

T00136 COPY_TAPE 3590-A 165,680.7 85.3 Filling

T00437 COPY_TAPE 3590-A 181,879.2 99.0 Filling

T00563 COPY_TAPE 3590-A 129,105.2 91.3 Filling

T00662 COPY_TAPE 3590-A 129,961.2 100.0 Filling

T00678 FS_TAPE 3590-A 112,175.6 100.0 Filling

T00699 COPY_TAPE 3590-A 137,978.2 86.3 Filling

T00834 COPY_TAPE 3590-A 102,698.5 99.5 Filling

T01029 COPY_TAPE 3590-A 108,112.7 100.0 Filling

T01133 COPY_TAPE 3590-A 157,369.6 87.3 Filling

T01401 COPY_TAPE 3590-A 141,794.7 100.0 Filling

T01536 COPY_TAPE 3590-A 160,104.6 95.5 Filling

T01562 COPY_TAPE 3590-A 160,695.3 100.0 Filling

T02069 FS2_TAPE 3590-A 156,554.5 100.0 Filling

T00001 FS_TAPE 3590-A 178,507.1 71.4 Full

T00143 COPY_TAPE 3590-A 195,464.2 100.0 Full

T00316 COPY_TAPE 3590-A 181,675.1 99.1 Full

T00362 FS2_TAPE 3590-A 203,831.8 75.7 Full

T00450 FS2_TAPE 3590-A 296,882.8 83.4 Full

T00655 FS2_TAPE 3590-A 192,215.8 92.4 Full

T00680 COPY_TAPE 3590-A 208,985.6 99.8 Full

T00870 COPY_TAPE 3590-A 215,645.8 100.0 Full

T01282 COPY_TAPE 3590-A 201,599.1 100.0 Full

T01723 COPY_TAPE 3590-A 201,970.6 96.8 Full

T00003 COPY_TAPE 3590-A 35,341.1 100.0 Full

T00006 EXCH_TAPE 3590-B 36,670.8 75.7 Full

T00020 SQL_TAPE 3590-B 35,172.7 50.4 Full