Hi,
> 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.
Yes, I'm understanding this but still expected to see jumps in
size while checking over a 20 minute or more chunk of time.
>
> >[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?
>
Yes, this is strange since I was using 'du' as much as 'df' yet
neither were reflecting any increase in size over long periods of
time :)
> 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.
netstat -in gives:
>netstat -in
Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue
lo0 8232 127.0.0.0 127.0.0.1 8378387 0 8378387 0 0 0
hme0 1500 132.239.0.0 132.239.146.150 67444931 0 30298441 0 0 0
and I know that our network switches are full duplex. Does this make me a
perfect candidate?
>
> 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.
>
You mean, if I notice unexpectedly slow network transfer times, try
the same operation the opposite direction?
--
Paul Yeatman (858) 534-9896 [EMAIL PROTECTED]
==================================
==Proudly brought to you by Mutt==
==================================
