#MAC OS FASTCOPY VERIFICATION#

I'll do some performance testing with rsync. I'm already using all the SATA ports of the MacPro (including one of the hidden ones), and anyway, the clients need to take the files in enclosures with USB and Firewire, not raw disks. I got it temporarily with FastCopy, but I'd like to centralize these operations on the MacPro that is already doing a lot of other I/O (including LTO-4 backups), where I'm sitting most of the time and where I have all my terminals and ssh sessions.

The source is an FC-connected SAN with 20TB (the fastest volume is 300MB/s, the slowest is 90MB/s)Cinema work being what it is, you tell someone that he can colour-correct until Friday and then they forget to set aside the time in the schedule to export the files - and they bring discs with USB2.0 (2.5TB 20MB/s? Do the math!!). Each folder ('reel') is around 350GB (aprox 30000 files), a film is usually 2.5 TB. TIF image sequence files for Digital Cinema. I don't suppose your machine has the capabilities to just hot-plug in an addition RAID 'mirror', with some sort of means to monitor the mirror build progress, does it? If this was the case, you could plug in the destination-drives as a new mirror of the array and let the RAID hardware deal with building the clone, which should be extremely fast. As the italicised text above says, rsync *automatically checksums as the file is transferred* so the -checksum isn't necessary and will just slow things down significantly as it'll do a complete read of all the data to generate the checksums as it's building the file list on both source and destination sides, before it even starts the copy.It'd be worth using the -W, -whole-file switch as this may provide a speedup (though this should already be the default when both the source and destination are specified as local paths).Can you explain what you're doing in a bit more detail? Why d'you need something like FastCopy or rsync, is it in case the operation's interrupted and you have to resume? Otherwise, what's wrong with the OS's built-in copy, which is possibly the fastest option? Is there data already on the external drives you're copying to that needs checking/merging, or is it one-way? How are the external disks configured, are you copying sections of data to each one? I'm guessing you're cloning something like edited video or audio off your RAID array to empty external drives for backup or transport to another location, with the need for some sort of resume or additional verification.

#MAC OS FASTCOPY VERIFICATION#

The receiver generates its checksums when it is scanning for changed files, and will checksum any file that has the same size as the corresponding sender's file: files with either a changed size or a changed checksum are selected for transfer.Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred, but that automatic after-the-transfer verification has nothing to do with this option's before-the-transfer 'Does this file need to be updated?' check. Generating the checksums means that both sides will expend a lot of disk I/O reading all the data in the files in the transfer (and this is prior to any reading that will be done to transfer changed files), so this can slow things down significantly.The sending side generates its checksums while it is doing the file-system scan that builds the list of the available files. This option changes this to compare a 128-bit MD4 checksum for each file that has a matching size. Without this option, rsync uses a 'quick check' that (by default) checks if each file's size and time of last modification match between the sender and receiver. From the manpage relating to this switch:quote:This changes the way rsync checks if the files have been changed and are in need of a transfer. The -c, -checksum switch is most-likely unnecessary for what you want. Quote:Originally posted by tigas:At least rsync has verify with the -c switch.

Mac os fastcopy