Sorry, but the trace doesn't mean anything to me.

However, sometimes doing some non-ADSM I/O to the file system can give you
a
good idea of whether your problem is in ADSM, or in the file system itself.

My question would be whether other file operations experience a slowdown?
If you do a DIR, does it take longer on this machine that it does on your
others?
If you can't navigate the file tree quickly via Windows commands, you can
be
pretty sure ADSM will have trouble, as well.

If this is a single Clariion disk, e.g. a real physical disk, my next
suggestion would be to run SCANDISK.  If this is a Clarrion RAID array,
have
you checked the Clariion box itself to make sure you aren't running in
backup mode?  (Our Clariion will run on parity with degraded performance if
a single disk of the array is actually down...)



> -----Original Message-----
> From: Sean Stecker [SMTP:Stecker.Sean AT ORBITAL-LSG DOT COM]
> Sent: Monday, March 08, 1999 4:11 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Slow backup part 2
>
>
>
> All,
>
> Some more info.  The ADSM Server is v3.1.2.0. The client is v3.1.0.6.
> They are
> both NT Server 4.0.  The filespace in question resides on a Clarion
array.
> It
> is 232 Gb.  We have not had this problem on other drives on this array.
 I
> am
> including a trace file that may help some of you more technical
> individuals as
> to the cause.  We are seeing it take up to 1/2 second to perform a
> GetStreamSize
> operation.  On other nodes and other drives on the same array, this
> operation
> takes exactly 0 seconds.  Could this multiplied by 700,000 be the
cause???
> We
> have tweaked and prodded and pulled every available tuning option, to no
> avail.
> All the transaction paramaters, memory usage, etc.
>
> Once again, your help is greatly appreciated.
>
> Sincerely,
>
> Sean M. Stecker
> stecker.sean AT orbital-lsg DOT com
>
>
> (See attached file: trace4.txt) << File: Text - character set unknown >>