I thought that a long time ago a restore had to recover the directories first
before it could recover the data. At that time implementing a separate storage
pool for directories that stayed on disk made sense in order to speed up
recovery.
For some time now a restore will lay down a dummy directory if it hits a file
that has to be restored before the directory is restored. As a result the need
to have directories in a separate pool seems to be less necessary.
Still, some people still implementing this separate storage pool for
directories when they have many windows clients. Large windows file servers may
have millions of directory objects that will be stored in a storage pool. Just
like backing up millions of small files if these objects are spread across many
tapes the restore will be slower. I have seen that you can cut 5 - 10% off of
the restore time when the directories are all on disk.
I would still use the DIRMC if you are a shop with many mgmt classes and a lot
of windows nodes. Lets say your MGMT class with the longest retention is called
"LONG". Your data goes to an MGMT class called "SHORT". If the storage pools
defined in both mgmt classes are collocated then the directory data for the
node will take up an extra tape in the storage pool defined to "LONG". Multiply
that, times enough nodes and it can make a difference. Further, if you have
more than one storage pool that has the longest retention then TSM randomly
determines which one to bind the data too. Lastly, if a new mgmt class is
created that has a longer retention then a lot of rebinding will happen.
I looked at what the redbook said I believe the redbook is speaking to an issue
that has long since been resolved.
Richard Sims <rbs AT BU DOT EDU> wrote:
>As per the TSM redbook at:
>
>http://www.redbooks.ibm.com/redbooks/pdfs/sg245416.pdf
>
>It suggests use of DISKDIRS and OFFDIRS to store directory information
>to avoid restore-time directory reconstruction hits.
>
>Everything makes sense, including the need to explicitly bind all
>directories on a client to the DISKDIRS management class with DIRMC.
>
>The next question is... *how* do you select ONLY directories for this
>management class without selecting any files within them, in dsm.opt?
>
>(Server is 5.1.8.0 on AIX and clients are 5.1.5.14/15 on Windows, Linux,
>Solaris, and AIX.)
...
Directories cannot be independently selected for a Backup or Archive
operation: they are implicitly backed up or archived along with files
unless you cause files only to be operated upon. Perhaps it would be
helpful if you posted the essence of what you are trying to achieve.
Note that you don't *need* to use DIRMc with Backup: you can use it for
"steering" purposes, but otherwise directories are bound to the management
class with the longest retention period. Note also that you have a mix
of Windows and Unix clients, wherein only the Windows directory info will
typically end up in a storage pool: as the redbook says, "On UNIX clients,
the directory entries are stored directly in the IBM Tivoli Storage Manager
server database" (unless ACLs are involved). With Unix directory info,
the DIRMc effects retention choice, but stgpool choice is not a factor.
I have notes on this stuff in http://people.bu.edu/rbs/ADSM.QuickFacts ,
as an adjunct to the primary IBM reference material.
Richard Sims
---------------------------------
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today
|
