Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] rsync v. cp in data migration



Something I haven't seen mentioned here is that rsync copies to a 'new' file
in the same directory as the target, then moves the copy over to the target
file.
You can bypass this behavior and directly overwrite the target using
--inplace when not using a network.

-----Original Message-----
From: discuss-bounces+joe=polcari.com at blu.org
[mailto:discuss-bounces+joe=polcari.com at blu.org] On Behalf Of Steve Harris
Sent: Friday, May 24, 2013 8:48 PM
To: discuss at blu.org
Subject: Re: [Discuss] rsync v. cp in data migration

Correct me if I'm wrong here, but....

1) Using a tar pipeline will (should) always be slower than a single process
(e.g., cp, cpio -p, rsync), because of the overhead of the two processes and
the system buffering for the pipe.

2) Copying to an NFS-mounted filesystem is likely to be less efficient than
alternatives (e.g., rsync) because of the NFS overhead -- it looks like a
local filesystem but in fact there is a lot of network processing happening
behind the scene.

3) I'm not an expert on rsync, but wasn't it (initially) written in a
client-server mode to achieve very high efficiency copying files over a
network?  Especially when updating (large) files which may have changed
slightly.

4) AFAIK, cp will not preserve hard links.  rsync will (though not by
default).  cpio and tar will by default.

- Steve
_______________________________________________
Discuss mailing list
Discuss at blu.org
http://lists.blu.org/mailman/listinfo/discuss




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org