ADSM-L

Re: Reclamation of Copy Dirs

2003-08-05 15:45:49
Subject: Re: Reclamation of Copy Dirs
From: "Lambelet,Rene,VEVEY,GL-CSC" <Rene.Lambelet AT NESTLE DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 5 Aug 2003 21:45:23 +0200
Hi, I think I remember having read something about stgp on disk with a
devclass of type FILE (sequential). Sending the dir's into such a seq stgp
would result in much faster recl and backups stgp.

Yours,

                René LAMBELET
                NESTEC  SA
                GLOBE - Global Business Excellence
                Central Support Center
                SD/ESN
                Av. Nestlé 55  CH-1800 Vevey (Switzerland) 
                tél +41 (0)21 924 35 43   fax +41 (0)21 924 13 69   local
K4-104
                mailto:rene.lambelet AT nestle DOT com

                This message is intended only for the use of the addressee
                and may contain information that is privileged and
confidential.
 

-----Original Message-----
From: Rushforth, Tim [mailto:TRushforth AT WINNIPEG DOT CA]
Sent: Tuesday,5. August 2003 21:16
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Reclamation of Copy Dirs


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

<Prev in Thread] Current Thread [Next in Thread>