I have some free time, and would like to spend it being paid to work for
the Freenet Project, which I am informed has the funds. Previously
prominent developers - oskar and tavin - have been paid $2500 for
approximately 2 months work on freenet. I would like to use the same
deal, and IMHO I am the only person available at the moment who has worked
on the code sufficiently AND has the time for it to be practicable.
I can work at least 35 hours per week, for most of the foreseeable
future. In particular, I can work from immediately to 2 months later.

There are a number of major unresolved issues with freenet at the
moment, but the one that has the greatest impact is probably the
DataStoreBug. The problem with this, apart from the fact that I don't
know fs/ very well, is that bugfixing is indeterminate. There are
however some things that can be done in this direction that are
reasonably determinate. For example, in order of desparation (reading
the docs/source first would be a good idea, fixing them up where
necessary would also be useful):
a Removing all the red-black trees, and converting them to skiplists.
  Not as trivial as it sounds, because the nodes are mutilated. This may
  not solve the bug, but it should simplify the code substantially for
  little cost (I have heard that the worst case cost is worse with
  skiplists... the consensus is that it's not bad enough to be a big
  problem though).
b Trying to prove that there is a problem with red-black trees, by making
  a tester that compares it with a skiplist (therefore faster than
  reverifying), more thoroughly. The current tests are based on special
  cases found while debugging the redblack tree.
c Reverse engineering the accounting structures, and documenting them.
d Find conditions likely to cause a DSB. Some people have reported
  getting it regularly.
e Making the fsck etc tools work reliably, at least to detect
  corruption.
f And to fix it, by rebuilding it.
g band-aid: do a read-only check (this may take a while) when starting
  the node, if it's broken, try to regenerate it, if that fails, reset
  the store.
h log all changes to the accounting tree (assuming migrating to
  skiplists etc hasn't fixed it), in a parsable format. Include a
  backtrace. Export the initial state of the tree. Checkpoint every
  timeperiod, either internally (more work), or by shutting it down
  and fsck'ing it externally. This gives us a period during which it
  corrupted. Then build up the tree, step by step, just as the node
  would have, fsck'ing after each completed change (or in a binary
  search, if this is computationally prohibitive, which I doubt), and
  find the exact instant of corruption. Then look at the backtrace, and
  fix the bug. This can also be converted into a regression test: run a
  node, checkpoint it every <moderate period of time> and fsck, keep the
  old state and log all changes since the clean old state along with
  backtraces, and email the list with a stack trace of the instant of
  corruption if/when we recorrupt. I am going to call this 'the nuclear
  option', and it requires a working accounting structures fsck and a
  good idea of what conditions will cause corruption; it's also probably
  best to try converting to skiplists first.

Not knowing the code intimately, I can only give very rough estimates
for the effort involved in each stage. How detailed do I need to make my
proposal? Need input.

-- 
Matthew Toseland
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Freenet/Coldstore open source hacker.
Looking for $coding (I'm cheap)

Attachment: msg03943/pgp00000.pgp
Description: PGP signature

Reply via email to