Re: [foxboro] Copying Displays to remote workstations

Tod,

On Wed, 2002-07-17 at 01:48, Baudais, Tod wrote:
> Thanks for the suggestions, but I still have a few concerns.
> 
> As I understand it, a lot of the available programs (such as rdist) want to
> keep identical copies of the files on different workstations based on
> modification dates and file sizes. The problem with that is the Display
> manager optimizes the displays when they are first opened, thus changing
> them. So the next time the script executes, the optimization gets wiped out
> - even if the display was "Up to date."  (Correct me if I am wrong here)
> 
This is the main reason for using rsync. It does not use the time stamp
of the file but actually does a checksum of the contents. It does this
in a way that is highly optimised for high latency,slow throughput
links.
Each end of the transfer does a checksum of the files and determines the
byte differences and offset into the file. Only these bytes are sent.
Eg: If you had to synchronise a large file, say 1 GB, that only had 1
byte difference, rsynch would compare the files and sent 1 byte and the
offset to update the target file.
Obviously to minimise traffic it should not be using an nfs/rfs file.
To minimise traffic rsync can rsh/ssh to the target machine and do the
update.

ie 
Machine 1       Machine 2
rsync -> rsh -> rsync

Rsync looks after all the gory details of the rsh etc by itself. Here's
a snippet from the man page.

       Perhaps the best way to explain the syntax is some examples:

              rsync *.c foo:src/

       this  would  transfer all files matching the pattern *.c from the
       current directory to the directory src on the machine foo. If any
       of  the  files  already exist on the remote system then the rsync
       remote-update protocol is used to update the file by sending only
       the differences. See the tech report for details.

              rsync -avz foo:src/bar /data/tmp

       this  would  recursively  transfer  all  files from the directory
       src/bar on the machine foo into the  /data/tmp/bar  directory  on
       the  local  machine. The files are transferred in "archive" mode,
       which ensures that symbolic links, devices,  attributes,  permis-
       sions,  ownerships  etc are preserved in the transfer.  Addition-
       ally, compression will be used to reduce the size  of  data  por-
       tions of the transfer.

              rsync -avz foo:src/bar/ /data/tmp

By the way the z option is to compress the data for the trip. This is
good for high latency/slow links but exercises the processors. When one
processor is much faster than the other you you can actually get a
slower synch than using uncompressed if you are using local traffic such
as ethernet.


> Thanks,
> Tod Baudais.
> 
> 
> 
>  
>  
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>  
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>  


 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: