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