We hope to have several of these "interface performance issues" fixed in
the next version. We will be using dynamic trees and better sorting
algorithms, among other things, to make navigating the filesystem faster.
We know this is very frustrating for users, and it is one of our priorities
for the next version.
Regards,
Brett Walker
ADSM Development
>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
>> ============================================================================
>>
o----------------------------------------------------------o
Brett Walker ADSM Development, IBM
walkerbl AT vnet.ibm DOT com
--------------------------------------------------------
"That's just my opinion; I could be wrong."
"That's just my opinion; I could be wrong."
--- Dennis Miller
|
