Làm thế nào để các chương trình có thể tiếp tục chuyển tập tin thất bại biết nơi bắt đầu nối thêm dữ liệu?

Một số chương trình sao chép tệp như rsyncvà curlcó khả năng tiếp tục chuyển / sao chép không thành công.

Lưu ý rằng có thể có nhiều nguyên nhân của những thất bại này, trong một số trường hợp, chương trình có thể "dọn dẹp" một số trường hợp chương trình không thể.

Khi các chương trình này tiếp tục, chúng dường như chỉ tính kích thước của tệp / dữ liệu được truyền thành công và chỉ bắt đầu đọc byte tiếp theo từ nguồn và nối vào đoạn tệp.

ví dụ: kích thước của đoạn tệp "đã tạo ra" đến đích là 1378 byte, vì vậy họ chỉ bắt đầu đọc từ byte 1379 trên bản gốc và thêm vào đoạn đó.

Câu hỏi của tôi là, biết rằng các byte được tạo thành từ các bit và không phải tất cả các tệp có dữ liệu được phân đoạn theo các đoạn có kích thước byte sạch, làm thế nào để các chương trình này biết chúng là điểm mà chúng đã chọn để bắt đầu thêm dữ liệu là chính xác?

Khi viết tệp đích là một loại bộ đệm hoặc "giao dịch" tương tự như cơ sở dữ liệu SQL xảy ra, ở cấp độ chương trình, kernel hoặc hệ thống tệp để đảm bảo rằng chỉ các byte được tạo sạch, được tạo thành tốt cho thiết bị khối bên dưới?
Hoặc các chương trình giả định rằng byte mới nhất sẽ có khả năng không đầy đủ, vì vậy họ xóa nó với giả định là xấu, lấy lại byte và bắt đầu nối thêm từ đó?

biết rằng không phải tất cả dữ liệu được biểu diễn dưới dạng byte, những dự đoán này có vẻ không chính xác.

Khi các chương trình này "tiếp tục" làm sao họ biết họ đang bắt đầu đúng nơi?

Để rõ ràng - cơ học thực sự phức tạp hơn để bảo mật tốt hơn - bạn có thể tưởng tượng hoạt động ghi vào đĩa như thế này:

• ứng dụng ghi byte (1)
• kernel (và / hoặc hệ thống tệp IOSS) đệm chúng
• khi bộ đệm đầy, nó được đỏ mặt với hệ thống tập tin:
  • khối được phân bổ (2)
  • khối được viết (3)
  • thông tin về tập tin và khối được cập nhật (4)

Nếu quá trình bị gián đoạn tại (1), bạn không nhận được bất cứ thứ gì trên đĩa, tệp vẫn còn nguyên vẹn và bị cắt ở khối trước. Bạn đã gửi 5000 byte, chỉ có 4096 trên đĩa, bạn khởi động lại chuyển ở offset 4096.

Nếu tại (2), không có gì xảy ra ngoại trừ trong bộ nhớ. Tương tự như (1). Nếu tại (3), dữ liệu được ghi nhưng không ai nhớ về nó . Bạn đã gửi 9000 byte, 4096 đã được viết, 4096 đã bị ghi và bị mất , phần còn lại chỉ bị mất. Chuyển hồ sơ tại offset 4096.

Nếu tại (4), dữ liệu sẽ được cam kết trên đĩa. Các byte tiếp theo trong luồng có thể bị mất. Bạn đã gửi 9000 byte, 8192 được ghi, phần còn lại bị mất, chuyển lại sơ yếu lý lịch ở offset 8192.

Đây là một đơn giản hóa mất. Ví dụ: mỗi lần ghi "logic" trong các giai đoạn 3-4 không phải là "nguyên tử", nhưng tạo ra một chuỗi khác (hãy đánh số thứ 5), theo đó, khối được chia thành các khối con phù hợp với thiết bị đích (ví dụ: đĩa cứng ) được gửi đến bộ điều khiển máy chủ của thiết bị, cũng có cơ chế lưu trữ và cuối cùng được lưu trữ trên đĩa từ. Chuỗi con này không phải lúc nào cũng hoàn toàn nằm dưới sự kiểm soát của hệ thống, do đó, việc gửi dữ liệu vào đĩa cứng không phải là một đảm bảo rằng nó đã thực sự được ghi và sẽ có thể đọc lại được.

Một số hệ thống tệp thực hiện ghi nhật ký , để đảm bảo rằng điểm dễ bị tổn thương nhất, (4), không thực sự dễ bị tổn thương, bằng cách ghi dữ liệu meta vào, bạn đoán nó, các giao dịch sẽ hoạt động ổn định bất cứ điều gì xảy ra trong giai đoạn (5).

Nếu hệ thống được đặt lại ở giữa một giao dịch, nó có thể tiếp tục đường đến điểm kiểm tra nguyên vẹn gần nhất. Dữ liệu được viết vẫn bị mất, giống như trường hợp (1), nhưng việc nối lại sẽ giải quyết vấn đề đó. Không có thông tin thực sự bị mất.

Lưu ý: Tôi chưa xem các nguồn của rsynchoặc bất kỳ tiện ích chuyển tập tin nào khác.

Thật là tầm thường khi viết một chương trình C nhảy phần cuối của tệp và có được vị trí của vị trí đó theo byte.

Cả hai thao tác được thực hiện với một lệnh gọi đến hàm thư viện C tiêu chuẩn lseek()( lseek(fd, 0, SEEK_END)trả về độ dài của tệp được mở cho mô tả tệp fd, được đo bằng byte).

Khi đã xong cho tệp đích, một lệnh gọi tương tự lseek()có thể được thực hiện trên tệp nguồn để chuyển đến vị trí thích hợp : lseek(fd, pos, SEEK_SET). Việc chuyển giao sau đó có thể tiếp tục tại thời điểm đó, giả sử phần trước của tệp nguồn đã được xác định là không thay đổi (các tiện ích khác nhau có thể thực hiện việc này theo các cách khác nhau).

Một tệp có thể bị phân mảnh trên đĩa, nhưng hệ thống tệp sẽ đảm bảo rằng một ứng dụng nhận biết tệp là một chuỗi tuần tự của các byte.

Về thảo luận trong các nhận xét về bit và byte: Đơn vị dữ liệu nhỏ nhất có thể được ghi vào đĩa là một byte . Một byte đơn yêu cầu ít nhất một khối dữ liệu được phân bổ trên đĩa. Kích thước của một khối phụ thuộc vào loại hệ thống tệp và cũng có thể phụ thuộc vào các tham số được quản trị viên sử dụng khi khởi tạo hệ thống tệp, nhưng nó thường nằm trong khoảng từ 512 byte đến 4 KiB. Các thao tác ghi có thể được đệm bởi kernel, thư viện C bên dưới hoặc bởi chính ứng dụng và việc ghi thực tế vào đĩa có thể xảy ra trong bội số của kích thước khối thích hợp dưới dạng tối ưu hóa.

Không thể ghi các bit đơn vào tệp và nếu thao tác ghi không thành công, nó sẽ không để lại "byte nửa viết" trong tệp.

Về cơ bản, đây là hai câu hỏi, bởi vì các chương trình như curl và rsync rất khác nhau.

Đối với các máy khách HTTP như curl, họ kiểm tra kích thước của tệp hiện tại và sau đó gửi Content-Rangetiêu đề với yêu cầu của họ. Máy chủ sẽ tiếp tục gửi phạm vi của tệp bằng mã trạng thái 206(nội dung một phần) thay vì 200(thành công) và quá trình tải xuống được tiếp tục hoặc nó bỏ qua tiêu đề và bắt đầu từ đầu và máy khách HTTP không có lựa chọn nào khác ngoài tải xuống lại mọi thứ lần nữa.

Hơn nữa máy chủ có thể hoặc không thể gửi Content-Lengthtiêu đề. Bạn có thể nhận thấy rằng một số tải xuống không hiển thị phần trăm và kích thước tệp. Đây là các bản tải xuống mà máy chủ không cho khách hàng biết chiều dài, vì vậy khách hàng chỉ biết số lượng đã tải xuống chứ không phải số lượng byte sẽ theo.

Một số trình quản lý tải xuống sử dụng một Content-Rangetiêu đề với vị trí bắt đầu và dừng được sử dụng để tải xuống một tệp từ các nguồn khác nhau cùng một lúc, giúp tăng tốc độ truyền nếu mỗi máy nhân bản của nó chậm hơn kết nối mạng của bạn.

Mặt khác, rsync là một giao thức nâng cao để truyền tệp gia tăng. Nó tạo tổng kiểm tra các phần của tệp trên máy chủ và phía máy khách để phát hiện byte nào giống nhau. Sau đó, nó chỉ gửi sự khác biệt. Điều này có nghĩa là nó không thể chỉ tiếp tục tải xuống, mà thậm chí nó có thể tải xuống các byte đã thay đổi nếu bạn thay đổi một vài byte ở giữa một tệp rất lớn mà không cần tải lại tệp.

Một giao thức khác được thực hiện để tiếp tục chuyển tiền là bittorrent, trong đó .torrenttệp chứa danh sách tổng kiểm tra cho các khối từ tệp, do đó, các khối có thể được tải xuống và xác minh theo thứ tự tùy ý và song song từ các nguồn khác nhau.

Lưu ý rằng rsync và bittorent sẽ xác minh dữ liệu một phần trên đĩa của bạn, trong khi tiếp tục tải xuống HTTP thì không. Vì vậy, nếu bạn nghi ngờ dữ liệu một phần bị hỏng, bạn cần kiểm tra tính toàn vẹn nếu không, tức là sử dụng tổng kiểm tra của tệp cuối cùng. Nhưng chỉ làm gián đoạn quá trình tải xuống hoặc mất kết nối mạng thường không làm hỏng tệp một phần trong khi mất điện trong quá trình chuyển có thể xảy ra.

TL; DR: Họ không thể, trừ khi giao thức mà họ sử dụng cho phép.

Các chương trình không thể luôn tiếp tục từ một vị trí tùy ý: ví dụ: các yêu cầu HTTP chỉ có thể khởi động lại nếu máy chủ hỗ trợ và máy khách thực hiện nó: đây không phải là phổ biến, vì vậy hãy kiểm tra tài liệu của chương trình của bạn. Nếu máy chủ hỗ trợ nó, các chương trình có thể tiếp tục chuyển bằng cách yêu cầu như một phần của giao thức. Bạn thường sẽ thấy chuyển một phần trong thư mục tải xuống của mình (chúng thường được đánh dấu bằng tiện ích mở rộng ".partial" hoặc một cái gì đó tương tự.)

Nếu quá trình tải xuống tệp bị tạm dừng hoặc tạm dừng, khách hàng có thể ghi tệp vào đĩa và có một ý tưởng nhất định về nơi tiếp tục. Mặt khác, nếu máy khách gặp sự cố hoặc có lỗi ghi vào tệp, máy khách phải cho rằng tệp bị hỏng và bắt đầu lại. BitTorrent phần nào giảm thiểu điều này bằng cách chia nhỏ các tệp thành "khối" và theo dõi những tệp nào đã được tải xuống thành công; hầu hết những gì nó sẽ phải làm lại là một vài khối. Rsync làm một cái gì đó tương tự.

Làm thế nào để các chương trình biết rằng nội dung là giống nhau? Một phương pháp là xác minh rằng một số định danh giống nhau giữa máy khách và máy chủ. Một số ví dụ về điều này sẽ là dấu thời gian và kích thước, nhưng có những cơ chế có thể dành riêng cho một giao thức. Nếu các định danh khớp, thì khách hàng có thể cho rằng việc tiếp tục sẽ hoạt động.

Nếu bạn muốn xác minh rõ ràng hơn, HTTP và bạn bè không nên là lựa chọn đầu tiên của bạn. Bạn sẽ muốn sử dụng một giao thức cũng có tổng kiểm tra hoặc hàm băm cho toàn bộ tệp và từng đoạn được chuyển đổi để bạn có thể so sánh tổng kiểm tra tải xuống với tổng kiểm tra máy tính của máy chủ: mọi thứ không khớp sẽ được tải xuống lại. Một lần nữa, BitTorrent là một ví dụ về loại giao thức này; rsync có thể tùy chọn làm điều này quá.

Phụ thuộc vào giao thức được sử dụng để chuyển. Nhưng curl sử dụng http và nó chuyển dữ liệu tuần tự theo thứ tự xuất hiện trong tệp. Vì vậy, curl có thể tiếp tục dựa trên kích thước tập tin của một lần chuyển hoàn thành một phần. Trong thực tế, bạn có thể lừa nó bỏ qua N byte đầu tiên bằng cách tạo một tệp có độ dài N (của bất cứ thứ gì) và yêu cầu nó xử lý tệp đó dưới dạng tải xuống hoàn thành một phần (và sau đó loại bỏ N byte đầu tiên).