Re: [Dibs-discussion] Congrats & some problems

[Emin M. <em...@al...>]

Thanks for the suggestion.  I think your idea is a significant
improvement to the current mode of operation.

Could you post this into a request for enhancement
(http://sourceforge.net/tracker/?group_id=69007&atid=523110) on
Sourceforge?  (It's easier for me to keep track of stuff and put it on
my to do list that way.)

Thanks,
-Emin


Christian Stork <dib...@cs...> writes:

>> <brainstorm>
>> DIBS could take the number N of current backup peers and encode every
>> file (independent of its size) as N parts, R of which are redundant.
>> Each peer will store one part.  If a part is larger than kbPerFile KB it
>> is subdivided so that its pieces stay below the limit.
>> </brainstorm>
>
> Two more remarks:
>
> 1. The above idea gets rid of the currently inefficent space use for
> files < kbPerFile (ie use of essentially regular copies).  Probably
> these are the majority of files!  (Especially with the new default
> kbPerFile setting in CVS of 10MiB.)
>
> 2. How to turn this into a not-too-complex configuration scheme:
>
> (I cleaned up the pieces vs parts vs files terminology wrt to above.)
>
> piecesPerFile  -- number of pieces that each file is split into
> redundantPieces  -- as before
>                     Invariant: redundantPieces < piecesPerFile
> maxKbPerPart -- Pieces are transmitted as "parts" each of which has to
> be smaller than maxKbPerPart (roughly the same as previous kbPerFile)
>
> Given these config options DIBS only starts to produce backups if the
> number of backup peers N is greater or equal to piecesPerFile.
> If this is not the case a warning should be issued when
> - the daemon is started, and
> - after add_peer and edit_peer commands.
>
> -- 
> Chris Stork   <>  Support eff.org!  <>   http://www.ics.uci.edu/~cstork/
> OpenPGP fingerprint:  B08B 602C C806 C492 D069  021E 41F3 8C8D 50F9 CA2F