[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd: Re: [rdiff-backup-users] Restarting development]

From: Josh Nisly
Subject: [Fwd: Re: [rdiff-backup-users] Restarting development]
Date: Tue, 06 Apr 2010 11:35:23 -0500
User-agent: Thunderbird (X11/20100317)

Oops, meant to include the list.
--- Begin Message --- Subject: Re: [rdiff-backup-users] Restarting development Date: Tue, 06 Apr 2010 11:32:11 -0500 User-agent: Thunderbird (X11/20100317)
Daniel Miller wrote:
I'm looking forwarding to hearing your responses.

Are you sure about that? :)
Absolutely! I really would be excited about another project that uses some of the same algorithms. As I said, more competition is good...

Here's my personal perspective. Our current users get grumpy when we change the wire protocol across major versions - I suspect that losing backwards compatibility at the repository level would be a deal-killer for many. (I know it would be for me, since I have hundreds of repositories with multiple years of history.) Because of that, I doubt that I'll contribute meaningfully to a new project. I'm also a little hesitant to call it rdiff-backup, since it is a complete rewrite. Maybe rdiff-backup-ng (or something like that) would be a good compromise?

Hmm, ok, I'll rename it. It will likely be a completely new project. I'd like to explore deduplication anyway, which requires an even bigger divergence from the rdiff-backup design (it will likely eliminate the current mirror in favor of a block-level database, but it solves a host of other cross-platform issues so its appealing to me).

As it is, I believe the current repository design is flawed with a performance issue that gets worse with bigger backup sets and long-term use. I don't know if that can be fixed without changing the repository structure. You also mentioned that unicode support will require a transition period--I'm not sure if this implies changing the repository structure, but thats what it sounds like to me.
I've not had any problems with performance on large data sets that change often. My backups typically only run once a day though, so I rarely have more than a few million increment files per repository.

The unicode changes will require some repository changes, but the changes will necessarily be backwards compatible, and won't entail structural changes.

The more I think about it, the more I think starting another project isn't an all bad solution - I think we may have increasingly divergent goals. For myself, having a current mirror is well worth the cost in disk space; it means that it's much easier to recover from a file corruption or program bug. OTOH, loosing this requirement opens the door to other features.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]