I meant to add that due to the sheer amount of data (and time needed) to copy, you really don't want to use copying tools which abort on error, such as MS Explorer.
Normally I'd suggest something like FAR in Windows or Midnight Commander in Unix to copy over networked connections (CIFS shares), or further on - tar/cpio/whatever. These would let you know of errors and/or suggest that you retry copying (if errors were due to environment like LAN switch reset). However, interactive tools would stall until you answer, and non-interactive tools would not continue copying over what they lost on the first pass. Overall from my experience, I'd suggest RSync running in a loop with partial-dir enabled, for either local copying or over-the-net copying. This way rsync takes care of copying only the changed files (or continuing files which failed from the point where they failed), and it does so without requiring supervision. For Windows side you can look for a project called cwRsync which includes parts of Cygwin to make the environment for rsync (ssh, openssl, etc). My typical runs between Unix hosts look like: solaris# cd /pool/dumpstore/databases solaris# while ! rsync -vaP --stats --exclude='*.bak' --exclude='temp' --partial --append source:/DUMP/snapshots/mysql . ; do sleep 5; echo "===== `date`: RETRY"; done; date (Slashes in the end of pathnames do matter a lot - directory or its contents) For Windows the basic syntax remains nearly the same, I don't want to add confusion by crafting it out of my head now with nowhere to test. If your setup is in a LAN and security overhead can be disregarded, use 'rsync -e rsh' (or use ssh with lightweight algorithms) to not waste CPU on encryption. Alternatively, you can configure the Solaris host to act as an rsync server and use the rsync algorithm (with desired settings) directly. Also, if your files are not ASCII-named, you might want to look at rsync --iconv parameter to recode pathnames. And remember about ZFS 255-byte(!) limit on names. For Unicode names the string character length is roughly half that. //HTH, Jim -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
