(These are more or less excerpts from the disscussion list:)
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.
This 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.)
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 (but with 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,
- after delete_peer, and
- after add_peer and edit_peer commands.
Log in to post a comment.
