Daniel Miller wrote:
I wasn't really prepared to make this announcement so soon, but now seems like
a good time to let the community know. I've been working on a new
implementation of rdiff-backup since about a month ago when I dug into the
current codebase and discovered its disappointing quality. While what I have
right now is functional and works on simple cases, it does not cover the broad
range of features currently offered by rdiff-backup. I could use some help in
bringing it up to par if others are interested in the path I have taken. While
I have used the current codebase for direction and inspiration, I have started
with a clean slate for several reasons:
I'm interested and am looking forward to seeing the code.
- An automated test suite makes adding new features and long-term maintenance
much easier. Adding this to the current codebase is both hard and boring. One
thing that makes it very hard to write tests for the current codebase is the
widespread use of globals. My new implementation has been developed using TDD
and minimal use of globals (e.g. for loggers and constants).
YAY TDD! :)
- The current repository layout has a critical design flaw that causes
performance degradation as a repository grows. Most difference information is
stored in a single file tree (rdiff-backup-data/increments), that has a very
similar structure to the mirror. The problem is that as files get
added/deleted/changed the directories in the increments tree are always growing
in size, meaning it takes longer and longer to list the contents of directories
in the tree. This performance problem is negligible in small-to-medium sized
backup sets, but becomes apparent in very large backup sets as the number of
increments grows. I have redesigned the repository layout in my new
implementation to eliminate this performance issue. Note that I do not know for
sure if my new layout will completely eliminate this problem since I have not
tested it yet with a very large backup set over a long period of time.
Can this be tested further? It would suck to get further down the road
with this repository structure and find out it didn't really help the
problem.
--------------------------------------
Randy Syring
Intelicom
502-644-4776
"Whether, then, you eat or drink or
whatever you do, do all to the glory
of God." 1 Cor 10:31
_______________________________________________
rdiff-backup-users mailing list at [email protected]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki