OK, I'll take a stab at this: You are pretty plainly asking for more
files to be restored than you realize. Specifying a simple subdirectory
to be restored, from even a filespace containing a vast number of files,
is fast. e.g. RESTORE /var/mail/johndoe/* Our end-users do it all the
time with the Unix linemode client dsmc command interface, and they're
not phoning me to complain that it performs badly. Every time you run an
ordinary incremental backup for this client node, a similar process
happens so that the TSM client program can figure out which files need
to be backed up this time. The "diff" is done on the client system after
downloading the full list of that node's files from the server to the
client. If that were as slow as you report, normal backups could never
happen. So something else has to be wrong, such as asking to restore a
lot more files than you really wanted, so that the list it is building
of the files you want restored is growing wildly.
Perhaps this is a typo in a wildcard specification. Perhaps you need to
specify a fully-qualified path here but you are only specifying a
relative path. Try specifying the -pick option on the restore command,
and see how many files it comes up with for you to pick from. Try
copying the exact specification you are using on the dsmc restore
command, into a unix ls command, and see how many files it lists. You
might be surprised with a lot of files - that you didn't want.
Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED]
Academic Computing & Communications Center
On Mon, 10 Mar 2003, Thomas Denier wrote:
>We are attempting to perform a point in time restore for one of several
>thousand users on a large mail server. The file system involved contains
>almost four million files. The server is at level 4.2.3.2 and running
>under OS/390. The client is at level 5.1.1.0 and running under Linux
>at a 2.4.9-34s kernel level. The system administrator has declined to
>offer any estimate of the number of files to be restored. Several
>attempts to carry out the restore have been terminated to allow normal
>backup processing to run. In desparation we have suspended normal
>expiration and reclamation processing to enable the restore to get as
>much of the server's resources as possible. We also restarted the
>server to ensure that server memory management was as clean as possible.
>The restore has been running for nearly an hour with no data movement to
>or from the client and no tape mount requests. It is presumably figuring
>out which files to restore and where the files are located. Tivoli
>has never thought it necessary to provide any sort of progress indicator
>for this kind of processing. However, 'query db f=d' commands show
>almost eight million buffer requests, most of them presumably from the
>restore. How does the number of buffer requests scale with the number
>of files to be restored?
>
