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
> > ============================================================================
> >
|