BackupPC-users

Re: [BackupPC-users] Problems with hardlink-based backups...

2009-08-31 23:50:21
Subject: Re: [BackupPC-users] Problems with hardlink-based backups...
From: Marty <martyb AT ix.netcom DOT com>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Mon, 31 Aug 2009 22:27:30 -0400
Holger Parplies wrote:
> Hi,
> 
> Marty wrote on 2009-08-31 19:58:58 -0400 [Re: [BackupPC-users] Problems with 
> hardlink-based backups...]:
>> Peter Walter wrote:
>> > [...]
>> > If I had a method of simply backing up the changed files on the 
>> > backup server, and a method of dumping the hardlinks in such a manner 
>> > that they could be reconstituted later, then that would suffice.
>> 
>> I have not followed this thread
> 
> ... or other threads ...
> 
>> so I may have missed somebody else making this point,
> 
> ... or pointing out why it is wrong ...

Sorry, I should have scanned the archives.

>> but recent versions of rsync have solved the memory hogging
>> issue,
> 
> Nope, they have not, and they can never. Yes, protocol level 30 behaves
> better, but you still need a full list of all inodes with more than one link
> and one path to that inode. At some point in file count (which has *nothing*
> to do with pool size ... 220MB, 220GB or 220TB could potentially be the same
> number of files) it will stop working. Before that point it will work. It will
> likely get slower and slower as it approaches the point. But the point exists,
> and will continue to do so, as long as there is no syscall
> link (dev_t device, ino_t inode, char * newpath) ...
> 
> Thinking about it, the rsync source structure is not confined to a single file
> system, so rsync will actually need a (dev_t, ino_t) => path mapping.
> 
> Before protocol level 30, rsync will likely run out of memory for the file
> list long before the inode table becomes a problem, so, yes, protocol level 30
> is probably a big gain, but it still doesn't scale.

Are you saying this is just an rsync problem, or an exponential scaling
issue that no known algorithm can reduce to O(n)?

> 
> I wish I would find the time to add that to the wiki.

I for one would appreciate it.  Thanks for the great software.

> 
> Regards,
> Holger
> 

Marty


------------------------------------------------------------------------------
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/

<Prev in Thread] Current Thread [Next in Thread>