Re: File devclass change at server 5.3.x

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 <Dave.Frost AT SUNGARD DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
02/21/2006 08:56 AM
Please respond to "ADSM: Dist Stor Manager"

        To:     ADSM-L AT VM.MARIST DOT EDU
        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:dave.frost AT sungard DOT com
____________________________________________________
Keeping People and Information Connected (TM)
http://www.availability.sungard.com