Re: [Dibs-discussion] Congrats & some problems

[Christian S. <dib...@cs...>]

A little follwo-up to my own post... ;-)

On Sat, Sep 25, 2004 at 02:30:28PM -0700, Christian Stork wrote:
...
> <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