FW: rsync performance

[jw schultz]

On Fri, Sep 12, 2003 at 08:46:42PM -0400, Jim Salter wrote:
> > I'm sorry that you find rsync's local performance
> > disappointing but that isn't what rsync is really for.
> > If you do find specific enhancements that can be made that
> > won't adversely affect portability we'd be glad to hear of
> > them.
> 
> JW - one thing that occurs to me is to wonder if it would be possible to
> implement an RSYNC switch to allow use of a different utility for actual
> file copying... for example, the SMBFS implementation under FreeBSD is
> hideously broken and buggy for large copying operations, whereas smbclient
> works beautifully.  It would be *incredibly* useful if it were possible to
> use rsync's file comparison engine with alternate file *transfer* methods,
> such as for instance getting file names, sizes, and dates using smbclient or
> ftp, deciding which ones needed updating normally, and then again using
> smbclient or ftp to perform the actual updates - presumably only by whole
> file replacement, as obviously getting checksums wouldn't be reasonable.
> 
> I understand that you may not be interested / your immediate reaction might
> be "that's not what rsync is for", but further modularizing the design to
> allow for alternate file transfer methods would be very, very, very, very
> useful in an awful lot of situations.
> 
> Thanks for listening.

rsync --dry-run will give you a significant subset.

There is nothing magic about rsync's file comparison engine.
All it is doing is checking mtime and size for file
contents, and owner, group, and perms for metadata changes.

ls -l gives you all the data rsync is using.  You could
combine "find -ls | sort" with comm or diff to generate the
generate the core logic of rsync's file selection.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt