Skip to content

prevent corrupt downloads after app and/or system crash #1644

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jun 25, 2020

Conversation

aliemjay
Copy link
Contributor

Problem:
Segments (technically , chunks of in-flight pieces) are marked as finished in the control file (*.aria2) as they are downloaded, though they might not be permanently written, yet, to the storage medium. In the case of app or system crash, and after resuming the download, some segments might have been lost, but the control file marks them as finished.

There is as significant chance for this to happen because of the delay introduced by the in-app disk cache and the OS buffers before the actual physical disk write. By default, auto-save interval is 60 seconds, while, in my case, linux buffer cache had >15s delay and the delay of in-app caches are highly dependent on the download speed because they are flushed once a whole piece completes, which makes it worse for slow network or parallel downloads.

Solution:
Flush data from the caches before saving control file.

aliemjay added 2 commits June 17, 2020 11:05
Otherwise, some pieces may be marked as finished in the control file
though they have not yet been written to the storage file.

This should prevent data loss and corruption when resuming downloads
after an app crash.

Signed-off-by: Ali MJ Al-Nasrawy <alimjalnasrawy@gmail.com>
This ensures that pieces are physically written to disk before
marking them as finished in the control file.

This should prevent data loss and corruption when resuming downloads
after a system crash.

Signed-off-by: Ali MJ Al-Nasrawy <alimjalnasrawy@gmail.com>
@aliemjay
Copy link
Contributor Author

Hi @tatsuhiro-t, can you trrigger the travis-ci build again? It failed for OSX with a message The job exceeded the maximum time limit for jobs.

I tested both linux and windows builds locally before submitting the PR and it worked as expected.

@aliemjay aliemjay closed this Jun 20, 2020
@aliemjay aliemjay reopened this Jun 20, 2020
@tatsuhiro-t tatsuhiro-t merged commit 15cad96 into aria2:master Jun 25, 2020
@tatsuhiro-t
Copy link
Collaborator

Good catch. Thank you for PR. Merged now.

@888520ll19811209ll
Copy link

linlong

@aliemjay aliemjay deleted the sync-caches branch January 4, 2023 07:05
@@ -685,7 +685,7 @@ std::shared_ptr<DiskAdaptor> DefaultPieceStorage::getDiskAdaptor()

WrDiskCache* DefaultPieceStorage::getWrDiskCache() { return wrDiskCache_; }

void DefaultPieceStorage::flushWrDiskCacheEntry()
void DefaultPieceStorage::flushWrDiskCacheEntry(bool releaseEntries)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK here it go"s

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thankyou

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants