-----------
I've seen at least 4 notes with this same complaint within the last 2
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
> ============================================================================
>
|