Re: Finding a large object on IFS

[rob@xxxxxxxxx]

IBM has commands called:
RTVDIRINF
PRTDIRINF
to match
RTVDSKINF
PRTDSKINF
only the DIR commands are more IFS oriented.  Now, as they are currently 
written, the performance sucks.  How bad do they suck?  Well, we just put 
a new CEC in our 570 that took a batch job down from over 2 hours down to 
10 minutes.  The DIR commands take DAYS to run still.  I've been on IBM 
like stink on s...  They are in the process of rewriting them.  On the 
smaller lpars they can often get done under a day.

We ended up writing our own using IFS api's to drill down.  We get a 
summary report between today and the previous day and which directory grew 
by how much and what percent growth is that.  We can also query our own 
detail file to find the biggest ones.
*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....
  GDIHQ                       DISK ANALYSYS REPORT  
                      DATE ONE            DATE TWO  
                    07/07/2006          07/10/2006  
/                   6,821,719           6,821,719  
/bpcsdata              58,728              58,728  
/certs                 17,139              17,139  
/craigs             1,544,666           1,544,666  
/dev                  114,688             114,688  
/editpdta           1,597,048           1,688,612             91,564 5.73
/etc                   33,436              33,436  
/fixes                 65,536              65,536  
/home             217,882,272         217,882,272  
/java              31,899,068          31,899,068  
/kevinr                 8,203               8,203  
/les                    8,192               8,192  
/msfdebug               8,192               8,192  
/peggy              6,823,936           6,823,936  
/ptf                    8,192               8,192  
/qtemp                 19,742              19,742  
...
/GDDATA        14,578,057,890      14,532,962,052         45,095,838-  
.30-
/GDM                   61,255              61,255  
/GDSHELP        2,981,611,004       3,001,628,842         20,017,838  .67 
/GDSSALES       3,348,950,327       3,372,342,553         23,392,226  .69 
/InstallSh             19,489              19,489  
/INTERNOTE      1,727,982,756       1,750,900,960         22,918,204 1.32 
/JWALK             67,968,990          67,968,990  
/KRONOS           124,064,295         124,064,295  
/LEISERVE       1,019,216,497       1,019,690,395            473,898  .04 
...
/NOTES01      436,183,026,362     435,742,041,706        440,984,656-  
.10-
...
/QFPNWSSTG  2,535,369,352,030   2,535,369,352,030
/QOpenSys      82,950,150,788      82,950,150,788
...
/QUALITY       34,258,836,941      33,493,463,546        765,373,395- 
2.23-
/REPTEMP               16,384              16,384  
/REPTEMPÖ               8,192               8,192  
/SupplySyn        161,999,236         173,595,556         11,596,320 7.15 
/SAMETIME0      1,054,837,570       1,053,185,185          1,652,385-  
.15-
/SEAJWK             6,672,405           6,672,701                296  
/SSA36                944,294             950,195              5,901  .62 
/STAFFMARK          1,599,433           1,599,433  
/TrustedLi             16,384              16,384  
/TurnOver         128,769,560         128,769,560  
/WEB                   12,186              12,186  
            3,169,852,541,332   3,168,674,366,227      1,178,175,105-  
.03-
Note:  Our custom report omits QSYS.LIB.  As you can see we keep over 3TB 
in the IFS.  A bulk of it is in QFPNWSSTG which is used by our Linux lpar 
and all of our IXS cards.

Rob Berendt