rsync and hard links

John rsync at computerdatasafe.com.au
Thu Sep 30 01:05:50 GMT 2004


Wayne Davison wrote:

>On Wed, Sep 29, 2004 at 01:36:14PM +0800, John wrote:
>  
>
>>Is there something in the above options I should add or remove?
>>    
>>
>
>I don't see anything wrong that should prevent the hard-linking from
>happening.  If you do an "ls -li" on the source files, do they all show
>the same inode number?  I'll run some tests, just to make sure that that
>the options you cite work for me.
>  
>
$ \ls -li */var/tmp/backup.iso
17990639 -rw-r--r--    5 summer   summer   4547411968 Sep 14 18:41 
20040922-0616-wed/var/tmp/backup.iso
17990639 -rw-r--r--    5 summer   summer   4547411968 Sep 14 18:41 
20040922-0645-wed/var/tmp/backup.iso
17990639 -rw-r--r--    5 summer   summer   4547411968 Sep 14 18:41 
20040922-0710-wed/var/tmp/backup.iso
17990639 -rw-r--r--    5 summer   summer   4547411968 Sep 14 18:41 
20040922-1841-wed/var/tmp/backup.iso
17990639 -rw-r--r--    5 summer   summer   4547411968 Sep 14 18:41 
latest/var/tmp/backup.iso

>  
>
>>Rather than transferring a directory and all its contents amounting to 
>>some tens of thousands of files, would I be better off making a 
>>filesystem in a file:
>>dd if=/dev/zero seek=$((20*1024*1024)) count=0 bs=1024 of=20-gig
>>mke2fs -F -q 20-gig
>>and then transferring that?
>>    
>>
>
>The downsides of that are that (1) you don't get any benefit of skipping
>files that are already up-to-date (since it will update the entire
>20-gig of data every transfer) and (2) the block size will be pretty
>large, so there won't be as much matched data (so more data will have to
>be resent over the wire).
>
>  
>
What determines the blocksize?
Is overriding it a Bad Idea?

Is there a better plan?






More information about the rsync mailing list