[Top][All Lists]

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

Re: [Duplicity-talk] zfec v s. par2 (and, hello there!) (was: Announcing

From: Peter Schuller
Subject: Re: [Duplicity-talk] zfec v s. par2 (and, hello there!) (was: Announcing D éjà Dup)
Date: Mon, 3 Nov 2008 23:09:42 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

> Consider also using zfec [1], a library that I maintain.  It has a  
> Python bindings and it is actively used in the Allmtydata-Tahoe-LAFS  
> project [2], and the flud project [3], at least.  zfec is based on  
> the long-standing, widely used "fec" library thanks to Luigi Rizzo  
> and many contributors over the years.  It seems to be much faster  
> than par2 for a few experiments that I tried (documented in the zfec  
> README.txt), but it is possible that I was using par2 wrong.

Looks a lot better than using par2, which would probably end up being
dependent on the command line tool.

I have not looked into zfec in detail yet, but the one downside seems
to be that (and please correct me if I am wrong), it cannot be used to
produce error correction data separate from the input data. For the
purpose of duplicity it might be nice to support reading the data
without use of the error correction library.

I still want to tackle this, but again I want to do some design
changes to the way backends handle file I/o before jumping onto the
FEC problem.

/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <address@hidden>'
Key retrieval: Send an E-Mail to address@hidden
E-Mail: address@hidden Web: http://www.scode.org

Attachment: pgpLHK7xZTm0g.pgp
Description: PGP signature

reply via email to

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