Peter Peltonen wrote:
> 
>> It is not just rsync - any file oriented technique will have the same 
>> problem.
>> The only way to match up the linked files is to build a table of filenames 
>> and
>> inode numbers as they are copied and look up the matching inode to find the
>> right name for the link.  The process doesn't scale well.
> 
> Does that mean it will get slower and slower to rsync the data when
> the amount of hard links increases?
> 
> So, what are the limits?

It just gets slower as the table size grows - and much, much slower if you fill 
ram and it goes into swap.  The current version of rsync is better in that it 
no 
longer keeps a copy of the entire target tree in memory as well.

> Currently I am rsyncing a TopDir which size is 27G. How do I find out
> how many hard links the directory tree contains?

The size of the content is not so much an issue as the number of hard links. A 
'find -type f -links +1 | wc -l' should show the number of linked filenames but 
that won't help much when you don't know how many you can handle.

> All _seems_ to go well (will I receive some errors in rsyncing if
> something goes wrong, or will it just stall)?

It will just not complete in the time you need it to.

-- 
   Les Mikesell
    lesmikesell AT gmail DOT com



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/