[mnet-devel] FEC parameters, backwards compatibility
Zooko
zooko at zooko.com
Sat Feb 8 03:33:26 GMT 2003
Someone asked on IRC [1] if the GF(2^16) mode of Rizzo's FEC was a good choice.
First of all, I question whether a large number of erasure code shares actually
makes any difference. It probably makes no difference to file robustness.
I.e., you could do 400 out of 1600, or you could just do 4 out of 16 and make
100 copies of each share. It certainly makes no difference in the simple model
where you have a certain probability of recovering each copy, and it eases
repair. That is: if you 1600 different shares with one copy each, and you lose
a copy, now you have 1599 different shares, any 400 of which are necessary and
sufficient to reconstruct. To replace the lost share you would have to perform
a whole reconstruction. If you had 100 copies each of 16 different shares, and
you lost a copy, you could make a new replacement copy from one of the other
99 copies of that share.
Nonetheless, I intend to do large numbers of shares in my mythical
"decentralized filestore format v2". The reason is that it makes a difference
to block size -- we can keep block sizes small (like 64 KB or 256 KB) even if
the file is huge (like 16 GB). The alternative is to allow blocks to be big
(like 1 GB), which means you have to have another layer of design to deal with
big blocks (streaming them on download, for one thing).
So I intend to do *both* GF(2^8) and GF(2^16), where we use the fastest one of
the two that is big enough to handle the current file. My envisioned parameters
make it so that "Zooko's decentralized filestore format" can handle 20 GB files
before running out of FEC GF() space. When this limit begins to chafe, I might
add support for GF(2^32).
Another topic I saw on IRC was backwards compatibility. I'm pretty sure we can
achieve smooth backwards compatibility by denoting the version somewhere early
in the metadata. I've worked out concrete formats that include this feature.
I'm not sure I want to actually go to the effort to support the old-style code
though! If someone else who cares more about backwards compatibility than I do
wants to manage the "roll-over" process then we can surely do it.
Regards,
Zooko
[1] server: irc.freenode.net, channel #mnet
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
mnet-devel mailing list
mnet-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mnet-devel
More information about the Mnet-devel
mailing list