If you look at the "$Object_Directory$" that adsm keeps internally and
assume they used meaningfull names you can assume how they might
shuffle the information given what they are using to track it.
Below are basically the table spaces within the adsm data base. For
example we might assume that when a file "expires" an entry is added
into the Expiring.Objects table (or maybe moved from an AF or BF
table) then when expiration runs it is basically just processing
entries in that table space by removing or flagging entries in the SS,
DF, and/or DSKV... table spaces...
Remember, there are as many correct ways to write programs as there
are programmers... some just might be more effecient than others.
I can say that where I've looked at these tables, they are very
compact using (so it seems) binary flags everywhere possible... so the
difference between having or not having pointers to blocks on tapes or
just flipping a single bit in a flag is NOT where the adsm DB growth
come from... it more so comes from the eight mile long path and file
names and those do get cleared during expiration...
Also remember that the activity log is stored within the data base so
if you keep many days of that, it will suck up a lot of space
Key: ->(AF.Backup.Optimization)<-
Key: ->(AF.Bitfiles)<-
Key: ->(AF.Clusters)<-
Key: ->(AF.Damaged)<-
Key: ->(AF.Segments)<-
Key: ->(AF.Vol.Clusters)<-
Key: ->(AF.Vol.Partial.Bitfiles)<-
Key: ->(AF.Vol.Segments)<-
Key: ->(AS.Segments)<-
Key: ->(AS.Volume.Assignment)<-
Key: ->(AS.Volume.Status)<-
Key: ->(Activity.Log)<-
Key: ->(Administrative.Attributes)<-
Key: ->(Administrators)<-
Key: ->(Analyst.Administrators)<-
Key: ->(Arch.Objs.ByDescription)<-
Key: ->(Archive.Descriptions)<-
Key: ->(Archive.Objects)<-
Key: ->(Authorization.Rules)<-
Key: ->(BF.Aggregate.Attributes)<-
Key: ->(BF.Aggregated.Bitfiles)<-
Key: ->(BF.Attributes)<-
Key: ->(BF.Super.Bitfiles)<-
Key: ->(Backup.Objects)<-
Key: ->(Client.Eventrules)<-
Key: ->(Client.Optionset)<-
Key: ->(Clientopt.Members)<-
Key: ->(Copy.Group.Ids)<-
Key: ->(Copy.Groups)<-
Key: ->(DF.Bitfiles)<-
Key: ->(DF.CachedBitfiles)<-
Key: ->(DF.Clusters)<-
Key: ->(DF.Damaged)<-
Key: ->(DF.MigrBitfiles)<-
Key: ->(DF.MigrCandidates)<-
Key: ->(DF.Segments)<-
Key: ->(DF.Vol.Contents)<-
Key: ->(DRM.Attributes)<-
Key: ->(DRM.Mach.Char)<-
Key: ->(DRM.Mach.Node)<-
Key: ->(DRM.MachName.MachId)<-
Key: ->(DRM.Machine.Definition)<-
Key: ->(DRM.Rec.Inst)<-
Key: ->(DRM.Recov.Media)<-
Key: ->(DRM.Rm.Mach.Association)<-
Key: ->(DS.Overflow)<-
Key: ->(DS.Segments)<-
Key: ->(DS.Shared.Blocks)<-
Key: ->(DS.Volume.Status)<-
Key: ->(DSKV0000000005)<-
Key: ->(DSKV0000000006)<-
...
Key: ->(Expiring.Objects)<-
Key: ->(Filespaces)<-
Key: ->(Interface.Attributes)<-
Key: ->(Interface.ClassContents)<-
Key: ->(Interface.ClassOpParms)<-
Key: ->(Interface.ClassOps)<-
Key: ->(Interface.Classes)<-
Key: ->(Interface.GroupMembers)<-
Key: ->(Interface.Groups)<-
Key: ->(Inventory.Attributes)<-
Key: ->(License.Node.Storage)<-
Key: ->(License.Summary)<-
Key: ->(LicenseManager.Attributes)<-
Key: ->(Licenses)<-
Key: ->(MMS.Drives)<-
Key: ->(MMS.Lib.Inventory)<-
Key: ->(MMS.Libraries)<-
Key: ->(Management.Class.Ids)<-
Key: ->(Management.Classes)<-
Key: ->(NodeId.Assignment)<-
Key: ->(Nodes)<-
Key: ->(Object.Ids)<-
Key: ->(Operator.Administrators)<-
Key: ->(Policy.Administrators)<-
Key: ->(Policy.Attributes)<-
Key: ->(Policy.Domain.Members)<-
Key: ->(Policy.Domains)<-
Key: ->(Policy.Sets)<-
Key: ->(Policy.StgPool.Limits)<-
Key: ->(Restore.Objects)<-
Key: ->(Restore.Sessions)<-
Key: ->(SS.Classes)<-
Key: ->(SS.Globals)<-
Key: ->(SS.Pool.Contents)<-
Key: ->(SS.Pool.Ids)<-
Key: ->(SS.Pools)<-
Key: ->(SS.Volume.Ids)<-
Key: ->(SS.Volume.Names)<-
Key: ->(Schedule.Assocation)<-
Key: ->(Schedule.Event)<-
Key: ->(Schedule.Node.Addresses)<-
Key: ->(Schedule.Pending)<-
Key: ->(Scheduler.Attributes)<-
Key: ->(Schedules)<-
Key: ->(Seq.Volume.History)<-
Key: ->(Server.Eventrules)<-
Key: ->(Server.Eventvectors)<-
Key: ->(Server.Information)<-
Key: ->(Sorted.Objects)<-
Key: ->(SpaceMan.Objects)<-
Key: ->(SpaceManExt.Objects)<-
Key: ->(Storage.Administrators)<-
Key: ->(System.Administrators)<-
Key: ->(Triggers)<-
______________________________ Reply Separator _________________________________
Subject: Re: ADSM DataBase growth ?
Author: Dan.Giles at unix,mime/DD.RFC-822=Dan_Giles AT manulife DOT com
Date: 7/29/98 4:58 PM
Bob,
The adsm database always does "self cleaning", so when something expires, it's
gone from the database. If you expire a relatively large number of files, you
should see the database usage actually drop. The space on the sequential volume,
however, will remain until reclamation is performed, though as far as adsm is
concerned, there is nothing.
From: Bob Barden <Bob_Barden AT AAL DOT ORG> on 07/29/98 03:15 PM GMT
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc: (bcc: ADSM)
Subject: ADSM DataBase growth ?
The question is when a dataset's version is available to be expired and we
have run Expire Inventory is that when ADSM frees the space in the DataBase
or is
there a place holder left in the database until Reclaimation is run. The
expired data is on a sequential storage pool.
Thanks....
|
