Actually a sequential access storage pool like Todd created would not have
the slow problem.  The problem was only with Disk stgpools.  (So that is the
other workaround if you don't want to upgrade to 5.1.5.2).

Tim Rushforth
City of Winnipeg

-----Original Message-----
From: Richard Sims [mailto:rbs AT BU DOT EDU]
Sent: August 5, 2003 2:11 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Reclamation of Copy Dirs

...
>After all that, the reclamation is going at a better rate.  I think it is
>because the one 1GB disk volume containing all of the directory objects
>was just too resource intensive to scan.  The 10MB volumes are much faster
>to scan through.  Personally, it doesn't make sense that a random access
>volume would have that much trouble finding the file, but I had read other
>posts with problems similar to mine, so I made those changes.

Todd - I believe that the major problem is that, with long-lived small data
       in Disk type storage pools that fragmentation over time makes for a
lot of extra overhead - just gets worse and worse.  It's not something one
would expect, living daily with OS file systems which do just fine with
many, many files.  It may be that non-hierarchical organization is at play,
making for performance issues when the stgpool gets "holey" over time.

  Richard Sims, BU