The fast resume table is not updated. #116

Closed
jlouis opened this Issue Sep 7, 2011 · 4 comments

Comments

Projects
None yet
1 participant
@jlouis
Owner

jlouis commented Sep 7, 2011

In particular, the fast_resume table contains a bitfield which is always 0. This is a regression on fast resuming after a restart of the client. The problem is that etorrent_torrent_ctl uses this state to skip over checking if present. It is present, always, with a state that "we have nothing". So when you restart etorrent, etorrent assumes that all torrents are not downloaded at all.

@ghost ghost assigned jlouis Sep 7, 2011

@jlouis

This comment has been minimized.

Show comment Hide comment
@jlouis

jlouis Sep 7, 2011

Owner

Some investigation:

When etorrent_torrent_ctl starts up, it will try to load its piece state off of the fast resume table. The idea is to blindly trust the table if it is there. If it is not, we want to check the individual pieces to build up the table. That is the goal anyway. The problem is that we call etorrent_piece:to_list/1 which will give us a list of indexes, say [0, 7, 13, 165] of the piece indexes we have. We then proceed to check only these indexes. Thus if the table is either empty, or is populated with all 0'es like it is, then nothing is checked and we will never ever check for data. That is rather bad.

The other problem here is that we store all 0'es. So we don't really store the right kind of state in the fast resume table in the first place and thus we can't rely on the table when we want to resume. This is the second problem.

Owner

jlouis commented Sep 7, 2011

Some investigation:

When etorrent_torrent_ctl starts up, it will try to load its piece state off of the fast resume table. The idea is to blindly trust the table if it is there. If it is not, we want to check the individual pieces to build up the table. That is the goal anyway. The problem is that we call etorrent_piece:to_list/1 which will give us a list of indexes, say [0, 7, 13, 165] of the piece indexes we have. We then proceed to check only these indexes. Thus if the table is either empty, or is populated with all 0'es like it is, then nothing is checked and we will never ever check for data. That is rather bad.

The other problem here is that we store all 0'es. So we don't really store the right kind of state in the fast resume table in the first place and thus we can't rely on the table when we want to resume. This is the second problem.

@jlouis

This comment has been minimized.

Show comment Hide comment
@jlouis

jlouis Oct 6, 2011

Owner

I have a fix for part 1. I am working on part 2.

Owner

jlouis commented Oct 6, 2011

I have a fix for part 1. I am working on part 2.

@jlouis

This comment has been minimized.

Show comment Hide comment
@jlouis

jlouis Oct 7, 2011

Owner

The 2nd problem is this: We call etorrent_torrent_ctl:valid_pieces/1 to figure out which pieces are valid. But this value in etorrent_torrent_ctl is only set at startup and never updated. So the piece set of valid pieces is never updated as intended and the internal state is wrong. This means we will always store an all-zero entry more or less and that accounts for a number of problems with respect to piece states.

Owner

jlouis commented Oct 7, 2011

The 2nd problem is this: We call etorrent_torrent_ctl:valid_pieces/1 to figure out which pieces are valid. But this value in etorrent_torrent_ctl is only set at startup and never updated. So the piece set of valid pieces is never updated as intended and the internal state is wrong. This means we will always store an all-zero entry more or less and that accounts for a number of problems with respect to piece states.

jlouis added a commit that referenced this issue Oct 8, 2011

Fix Issue #116.
There were two problems w.r.t to issue #116 in play here.

The first mistake was that when booting a torrent, we incorrectly
tried to filter and check pieces on disk. We fed a set of pieces to
check incorrectly, and this meant we did not correctly get to check
pieces.

The second mistake was that the torrent_ctl module has a state entry,
valid, which tracks valid pieces. That state entry was never updated
and so, when we stored information in the fast resume table, we always
stored the initial state of the torrent. Since the initial state is always
that no pieces are there, we could never track progress in the fast
resume table.
@jlouis

This comment has been minimized.

Show comment Hide comment
@jlouis

jlouis Oct 8, 2011

Owner

This has been fixed by a commit.

Owner

jlouis commented Oct 8, 2011

This has been fixed by a commit.

@jlouis jlouis closed this Oct 8, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment