No, I don't think it's the OS - the file tree is fairly bushy
(there may be 100 files in a directory, but there are many more
directories).  The restore finally failed with "out of memory"
errors, so I think it's ADSM.  Bummer.

Is there any real technical detail on how ADSM works anywhere?
I've been surprised to realize that, for all I _do_ know about
ADSM, there are lots of "under the hood" questions that I can't
seem to find detailed, authoritative answers for.  Am I just not
looking in the right places?

Pat Wilson
paw AT dartmouth DOT edu

peter jodda <oelsburg AT HOTMAIL DOT COM> writes:
> Pat Wilson wro e:
>  >I'm seeing ADSM restores of large filesystems (750,000 files) get CPU
>  bound
>  >on the client side (DU 4.0D client, ADSM v3.1.06).  I think it's the
>  same
>  >problem that's been talked about several times before - once about
>  100,000
>  >files arrive back on the client, things slow *way* down, though the
>  server
>  >is not busy.  Throughput goes from 400Kb/s at the beginning to a
>  paltry
>  >50-70 Kb/s as more files are restored, and the CPU is running 70%
>  busy
>  >(doing nothing else).
>
>  Couldn't this be a problem of the operating system or the underlaying
>  filesystem. I once created a directory with 70000 files in it.
>  Even a ls took over a minute, before any characters appeared on the
>  screen. As far as I know, the files in a directory are linked in a
>  linear list. So adding one file will lead to a scan of this list.
>  This is a quadratic effort O(n^2).
>  Because ADSM is above that filesystem, it has to wait, until the
>  filesystem operations are ready.
>
>  How much files are in one directory?