>I guess what was bothering me most was never actually seeing the data
>size of the client disk increase while amrecover (or, I guess,
>amrestore by that point) was running.  Maybe I had some egregiously
>uncanny timing for checking inbetween "writes" while the dump file was
>being parsed on tape.  ...

The dump image itself is not going to disk.  It's being passed in a
pipeline between amrestore and ufsrestore.  So while it's skipping files
that are not to be restored, nothing will be happening on the disk.

>[I] aborted amrecover, the directory size would "suddenly" 'du' as 20
>megs or so larger than the entire time I was checking it during the
>restore.  Is there any reasonable explanation for this?

Probably :-), but nothing pops to mind.  I've seen issues of df not
reporting things properly for a while after a change and assumed it was
some kind of buffering going on, maybe waiting on a file system sync
operation, but not du.  I think ufsrestore brings back files into their
proper location in the directory tree as temp names and then renames
them, so it's probably not an issue of bring them back at the top level
and then moving them into place.

>Now, for the entries in /etc/system that you mentioned at the end
>of your message, is it a good idea for anyone using Sun's dump and
>restore to have these?  ...

They have nothing (directly) to do with dump and restore.  They fix
a problem with the Solaris hme device driver (hence the "hme" in the
variable being set) by forcing full duplex since it cannot seem to auto
negotiate properly (or you could force it to half duplex -- depends on
what your switch wants).  If you don't have an hme interface ("netstat
-in"), the entries won't help.  And if you do, you need to be certain
how your switch/hub is configured, etc.

If you're having this problem, almost all network traffic will be
effected.  For instance, an ftp (binary mode) of several MBytes should
act pathetic.  Be sure to test it both directions as the problem sometimes
only shows up on one side.

>Paul Yeatman

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

Reply via email to