Crispin,
I'm quite a newbie to rsync, but I've taken a stab at answering your
questions. Hopefully, someone will look over my shoulder and correct
any errors.
Crispin Bivans wrote:
> I've read about people using rsync with smbmount on linux's so that rsync in
> 'effect' is syncing files to Windows shares without needing an rsync client
> on the Windows side. This appeals to me since I'm considering how to safely
> distribute files to remote field offices in several countries. Some of them
> have slow links (~128kbs in some) so I was looking forward to using rsync
> for its performance benefits but now I'm wondering if rsync would compare
> files quickly even when it appears to be a locally mounted filesystem
> (smbmount on same box as master files).
>
> The idea I'm thinking would be to have a nightly process that smbmount's
> various remote office servers and then rsync's files from the Linux to these
> local mount points. Would rsync 'read' files from the Windows share entirely
> before deciding if it should 'write' the file back to the remote office?
Yes, based on everything I (think I) know, this would not reduce your
data communication requirement, but increase it.
You can think about this in a number of ways -- if there is only one
rsync process (client or server) it must calculate all the checksums for
both the local copy of the file and the remote copy of the file. Since
that single process runs in one CPU, the files which are remote to that
CPU must be copied to be local to that CPU to allow the checksums to be
calculated.
(I'm wondering why anybody would use rsync in this situation -- I can't
imagine a situation where a "plain" file transfer isn't more efficient.
But, I'm a newbie, I may be totally confused, and then I'll learn
something.)
> Should I resort to using options to only compare based on file datestamps in
> order to get around this?
I don't think this would help. The comparison based on file datestamps
is used only to determine whether the remote and local copies of the
file match or not (IIUC). Once it is determined that they don't match
and must be rsync'd the rsync algorithm operates in the normal manner --
calculating simple checksums for each block of each file for an initial
comparison. (And then double checking with a more complex checksum
calculation, and transferring only the blocks that don't match.)
>
> Also, how are Windows file locking issues handled by people using a
> combination of rsync and smbmount (or rsync on windows client for that
> matter)? Is there a good general way to get around the fact that an EXE may
> be locked by people in the remote office using it when a new EXE needs to be
> copied in? Is it a non-issue because rsync has options to rename the old
> file before copying in the new one?
>
Sorry, I don't have any idea.
> Let me know if anybody has some general observations about using rsync with
> smbmount and how good a solution it is.
See above, but I'd be pleased to be proved wrong.
Hope this helps,
Randy Kramer
