ADSM-L

FW: Searching w/inactive turned on

1996-12-21 13:36:05
Subject: FW: Searching w/inactive turned on
From: Mike Collins <ecollins AT VNET.IBM DOT COM>
Date: Sat, 21 Dec 1996 11:36:05 -0700
Hi Folks,

Sorry that I don't have the answer for you but wanted to let you know
that many developers are currently on vacation.  I expect that these
questions will be addressed when people return in early Jan.

Happy Holidays.

Regards,

Mike Collins
ADSM Development


Paul Schwartz writes:
 > I would add this is our most pressing problem, and we may also need to look 
 > at
 > an alternative solution if it is not solved.
 >
 > Paul Schwartz
 > Alliant FoodService
 > ----------
 > From:   "John O'Neall"[COMPUSERVE:INTERNET:jon AT IN2P3 DOT FR]
 > Sent:   Friday, December 20, 1996 11:49 AM
 > To:     Multiple recipients of list ADSM-L
 > Subject:        Re: Searching w/inactive turned on
 >
 > -----------
 > I've seen at least 4 notes with this same complaint within the last 2
 > weeks, inclucing one of mine.  I also sent such a note in October, but
 > the only reply I got was from this same gentlemen, Werner Bauer, saying
 > that it was worse at his site than at mine, probably because of the
 > number of files involved.
 >
 > I sincerely hope someone at IBM is listening.  This is an isssue that
 > could force us to go look for another backup/archival system one day.
 >
 > IBM, some words of encouragement, please.  Regards -- John
 >
 > --------------------------------------------------------------
 > John O'Neall                     e-mail:  jon AT in2p3 DOT fr
 > Centre de Calcul de l'IN2P3      phone:   +33 (0)4 78 93 08 80
 > Villeurbanne, France             fax:     +33 (0)4 78 94 30 54
 >
 > On Tue, 17 Dec 1996, Werner Baur wrote:
 >
 > > Our biggest node holds 2,6 million files and 125 GB of data. The server
 > > is running on a RS6000 R24, 256 MB, ADSM 2.1.0.10. We keep two inactive
 > > version.
 > >
 > > Restoring or querying an active file is a matter of a few seconds.
 > > If you try to restore an inactive file even by specifing the complete
 > > pathname, you can go for a coffee. It takes 10 minutes to get the
 > > selection menu.
 > > If you try to restore inactive files by using -subdir=on or by using the
 > > GUI, you can go for lunch. It takes more than two hours!
 > > Don't ask what our users say to this behaviour.
 > > Like you I am looking for workarounds. The high number of files within
 > > one node is caused by 16,000 homedirectories of unix users within this
 > > node.
 > > I am thinking about splitting the homedirectories into separated
 > > filespaces, but I am not sure about the impact of dealing with that many
 > > filespaces.
 > >
 > > Werner
 > >
 > >
 > > Thomas A. La Porte wrote:
 > > >
 > > > I'm seeing very bad performance when searching for files to be
 > > > restored when I am viewing both active and inactive files. I'm
 > > > curious to know if there are problems with my configuration or if
 > > > this performance is typical.
 > > >
 > > > Server: ADSM/6000 v2r1 Level 0.8 on an SP2 wide node, 256MB ram
 > > >
 > > > The following is the results of 'q occ' on this particular
 > > > filespace:
 > > >
 > > > OSIRIS          /osiris2     3590CPOOL   1,443,285  346,581.62
 > > >
 > > > (yes, that's 1.4 million files, 338 GB of data)
 > > >
 > > > If I am searching for files to be restored (whether GUI or
 > > > command line), with inactive files turned on, it takes
 > > > approximately 45 minutes to build the directory tree. If I then
 > > > change directories it takes as much as five to fifteen minutes to
 > > > build a list of files in that directory. This makes browsing the
 > > > directory tree of this file structure nearly impossible. Is ADSM
 > > > not caching the initial list of files after taking 45 minutes to
 > > > build? There is little to no problem with performance if I don't
 > > > include inactive files, which I do not fully understand. I keep
 > > > two inactive copies for every file, which would suggest that any
 > > > degradation in performance should be on the order of 2x or 3x,
 > > > not two to three *magnitudes*.
 > > >
 > > > Looking for any ideas on how this performance my be optimized.
 > > >
 > > > Thanks. -- Tom
 > > >
 > > > "If I could dot the 'i' in a Michigan     Thomas A. La Porte
 > > >  game and the good lord came to take me   Archivist, Feature Animation
 > > >  the next day ... at least I could        DreamWorks SKG
 > > >  die happy." - Beano Cook, ESPN           <tlaporte AT anim.dreamworks 
 > > > DOT com>
 > >
 > > --
 > > ============================================================================
 > > Werner Baur
 > > Leibniz-Rechenzentrum     X.400:
 > > S=Baur;OU=lrz;P=lrz-muenchen;A=d400;C=de
 > > Barer Str. 21            RFC822:  Werner.Baur AT lrz DOT de
 > > D-80333 Muenchen           Tel.:  ++49-89-28928781
 > > Germany                     Fax:  ++49-89-2809460
 > > ============================================================================
 > >
<Prev in Thread] Current Thread [Next in Thread>