ADSM-L

Re: Searching w/inactive turned on

1996-12-20 03:47:40
Subject: Re: Searching w/inactive turned on
From: John O'Neall <jon AT IN2P3 DOT FR>
Date: Fri, 20 Dec 1996 09:47:40 +0100
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
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>