Hi Simon,
Simon Breden wrote:
> The plot thickens. I replaced 'cp' with 'rsync' and it worked -- I ran it a
> few times and it didn't hang so far.
>
> So on the face of it, it appears that 'cp' is doing something that causes my
> system to hang if the files are read from and written to the same pool, but
> simply replacing 'cp' with 'rsync' works. Hmmm... anyone have a clue about
> what I can do next to home in on the problem with 'cp' ?
>
> Here is the output using 'rsync' :
>
> bash-3.2$ truss -topen rsync -a z1 z2
> open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
>
The rsync command and cp command work very differently. cp mmaps up to
8MB of the input file and writes
from the returned address of mmap, faulting in the pages as it writes
(unless you are a normal user on Indiana,
in which case cp is gnu's cp which reads/writes (so, why are there 2
versions?)). Rsync forks and sets up a socketpair between parent and
child processes then reads/writes. It should be much slower than cp,
and put much less stress on the disk.
It would be great to have a way to reproduce this. I have not had any
problems. How large is the
directory you are copying? Either the disk has not sent a response to
an I/O operation, or the response was
somehow lost. If I could reproduce the problem, I might try to dtrace
the commands being sent to the HBA
and responses coming back... Hopefully someone here who has experience
with the disks you are using
will be able to help.
max
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
