We have now found ourselves to be victims of this change. TSM 5.3.3.0 on AIX 5.3 ML-4
For years now we've used a FILE storage pool for directories with good results. Now our directory storage pools are "full" because they've hit their MaxScratch limit, mostly by allocating volumes holding 100KB - 2 MB in a DevClass specifiying 50 MB volumes. Last night over 40 node sessions failed. I checked APAR IC48331 for an update. Aside from some workarounds that *might* offer a little relief, there isn't much there. Does anyone know of any other updated information? Or if there is an updated set of recommendations? Rarely do "upgrades" cause a 20-fold increase in system failures, but that is exactly what happened to us. Thanks in advance. Tab Trepagnier TSM Administrator Laitram, L.L.C. Dave Frost <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[email protected]> 02/21/2006 08:56 AM Please respond to "ADSM: Dist Stor Manager" To: [email protected] cc: Subject: File devclass change at server 5.3.x Hi *SMers At server version 5.3, there is an undocumented feature change to the FILE devtype (see IC48331) such that the minimum write size is now 256K. For most files, this is not a problem. However, if like us you have a disk based directory storage hierarchy (random_access -> disk-sequential_primary; disk-sequential_copypool), then this is a disaster. We used disk sequential so that we could reclaim aggregates. On average, we normally saw a total disk usage of 5-10GB max, with each full volume initially reading 100%, and containing 40,000+ directory objects per 64MB file. Now we are seeing a newly written Full volume (from reclamation) with a maximum of maybe 0.7%, and containing as many as 400 directory objects in a 64MB file. Required disk space naturally has gone through the roof. The circumventions in IC48331 have not had a terribly significant effect - a few tenths of a percent only. For the moment, we are increasing the size of the DIRS random access diskpools, not migrating out to serial disk, and ignoring the (hopefully minor) hit on fragmentation. But this still leaves the copypool. At one time, we used to backup up the DIRS pools to tape. Then we tried to reclaim a tape volume that must have been in use for more than a year, but still only had a percent or two used. After a few days of continuous reclamation we gave up, and deleted the volume, then discarded the tape. So for pure DIRS storage, tape is not a good option. So far, the only useable circurmvention we can see is to use server-to-server virtual volumes for copypool, and not to use seqential disk file for primary storage. Is there a better way? Regards Dave I think it's a beautiful day to go to the zoo and feed the ducks. To the lions. ____________________________________________________ Dave Frost Technical Consultant SunGard Availability Services (UK) Limited London Technology Centre Heathrow Corporate Park Hounslow UK. TW4 6ER Tel: +44 (0) 800 2799 166 Fax: +(0) 20 8080 8112 mailto:[EMAIL PROTECTED] ____________________________________________________ Keeping People and Information Connected (TM) http://www.availability.sungard.com
