raise the max piece size to 512 MiB and fix check when loading torrents #7736
Conversation
| // count blocks per piece, that's restricting this | ||
| max_blocks_per_piece = (1 << 15) - 1 |
There was a problem hiding this comment.
the reason this wasn't caught early was because this 15 should have been 14. The bitfield was probably changed without this changing.
|
|
||
| // ---- 64 bit boundary ---- | ||
|
|
||
| // the number of dirty blocks in this piece | ||
| std::uint32_t num_dirty:14; | ||
|
|
||
| // the number of blocks in the cache for this piece | ||
| std::uint32_t num_blocks:14; |
There was a problem hiding this comment.
by bumping this to 16 bits, the max piece size goes to 512 MiB
There was a problem hiding this comment.
yeah, that should be wider too
There was a problem hiding this comment.
How about
num_dirty?
And pinned?
There was a problem hiding this comment.
How about
num_dirty?And
pinned?
I hope you haven't lost sight of it. It is also 15 bits.
There was a problem hiding this comment.
I'm tempted to just fix the check rather than mucking about with this struct. Do you think there's a legitimate use for torrents with piece sizes this large? It really seems questionable
There was a problem hiding this comment.
Do you think there's a legitimate use for torrents with piece sizes this large? It really seems questionable
I only know that the problem was reported by users... In addition, what seemed meaningless yesterday or today will become commonplace tomorrow.
Support for 512 MiB piece size does not require major changes, so why not add it?
Still, I don't insist. The correct processing of limits is good in itself. But I would still expand the potential capacity in upcoming major update.
There was a problem hiding this comment.
I think it would be much more reasonable to grow torrents in the number of pieces, rather than piece size.
arvidn
force-pushed
the
max-piece-size
branch
from
596fb68 to
82528e3
Compare
| @@ -97,9 +97,9 @@ namespace libtorrent { | |||
| // priority factor | |||
| prio_factor = 3, | |||
| // max blocks per piece | |||
| // there are counters in downloading_piece that only have 15 bits to | |||
| // there are counters in downloading_piece that only have 16 bits to | |||
There was a problem hiding this comment.
I didn't see that the counter itself was changed. Just this comment... Or is it a 16-bit size already?
There was a problem hiding this comment.
num_blocks went from 14 bits to a uint16_t (i.e. 16 bits)
There was a problem hiding this comment.
num_blockswent from 14 bits to auint16_t(i.e. 16 bits)
Ah, I thought it was about something else.
arvidn
force-pushed
the
max-piece-size
branch
2 times, most recently
from
f0a1527 to
6c34b37
Compare
arvidn
force-pushed
the
max-piece-size
branch
from
6c34b37 to
790e0ab
Compare
|
alternative fix: #7740 |
No description provided.