You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently blocks are written to disk immediately in the same order that they arrive from peers (which in most cases is random). Quite obviously, this behaves poorly on storage devices with non-random access. We should implement an intermediate in-memory buffer of configurable size to hold the arriving blocks until a piece (or a number of pieces) is complete. When the piece(-s) is complete, it can be verified and written to disk. This will eliminate a big number of disk seeks, esp. if adjacent pieces are flushed to disk in one batch, and also the reads that are made during piece verification.
The text was updated successfully, but these errors were encountered:
Additionally (and in fact most importantly from the overall correctness of the program point of view), this will prevent writing invalid data to the end storage. While it is not significant in case of standard mode of operation, when the torrent data is fully downloaded and verified before being used, it is critical for streaming (e.g. media player will most probably crash when encountering invalid data).
Currently blocks are written to disk immediately in the same order that they arrive from peers (which in most cases is random). Quite obviously, this behaves poorly on storage devices with non-random access. We should implement an intermediate in-memory buffer of configurable size to hold the arriving blocks until a piece (or a number of pieces) is complete. When the piece(-s) is complete, it can be verified and written to disk. This will eliminate a big number of disk seeks, esp. if adjacent pieces are flushed to disk in one batch, and also the reads that are made during piece verification.
The text was updated successfully, but these errors were encountered: