Sync down improvements

Đang mở
  • Có gì không ổn?
#722 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
8/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
cloud, python
Lĩnh vực
cli, cloud

Hướng nghiên cứu

The sync-down download path and the --threads option are the starting points, with issue #720 as the referenced report of timeouts. The issue lists several separate proposals (per-file thread count, resumable downloads with a journal file, parallel parts, a .crdownload-style temp name) that are marked as backwards incompatible and needing a major version. Done would require a maintainer decision on which of these to pursue, so it is not a newcomer task yet.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement

Currently large file downloads use 10 threads per file, but --threads tells the sync process how many files to process at the same time, with a default of 10 --threads it's 100 download threads in total, which can cause some of them to time out if the source cluster has a high TTFB and local storage device is not fast enough. This has been observed in #720, but also others.

Configurability of download thread count should be improved.

Continuing broken downloads should be implemented somehow. As of today the native B2 server API does not allow for checking of checksums on the cloud side. Most likely it requires a separate "journal" file that would be flushed whenever we write a block, to indicate which parts of the file are written correctly (in case we use parallel downloader), or up to which point the file is correct.

B2 integration checklist says:

Downloads over 200MB should be split into parts and downloaded simultaneously. Once all parts are downloaded, the large file should be stitched together.
out of concern for performance, I think, but maybe if we have multiple download operations running simultaneously (due to sync down of many big files), then splitting them to smaller chunks is not good for anyone.

Finally, if a download operation is interrupted forcibly somehow, the client has a file with correct extension, maybe even correct size, but not necessarily correct data. In order to avoid this, Google Chrome adds a .crdownload extra extension to a file to indicate is has not been finished yet.

Most of those changes are backwards incompatible and would require a major version increase, so they should probably be done together.

Ngôn ngữ chính
Python
Star
638
Fork
138
Merge trung bình
8 giờ 27 phút
Pull request đã merge (30 ngày)
8

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Backblaze/B2_Command_Line_Tool

Tất cả issue của Backblaze/B2_Command_Line_Tool

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.