Do băng LTO có dung lượng dự phòng / không sử dụng?

Theo tôi hiểu, các băng LTO ghi dữ liệu trong "kết thúc tốt đẹp", trong đó gói thứ nhất sẽ giải mã băng vào ổ đĩa và gói thứ hai cuộn lại vào hộp mực. Quá trình này được lặp đi lặp lại nhiều lần, với ý tưởng là một khi đã kết thúc băng, tất cả các băng sẽ trở lại trong hộp mực và nó có thể được đẩy ra với một chút tua lại.

Tuy nhiên tôi đã nhận thấy rằng khi bạn đi đến cuối băng, ổ đĩa có vẻ như đã đi được một nửa chặng đường cuối cùng, và vì vậy, ổ đĩa dành một chút thời gian để cuộn lại băng trước khi đẩy nó ra, mặc dù nó đã báo cáo rằng cuối băng đã đạt được.

Đây có phải là do có một số dung lượng dành riêng trên băng, để cho phép những thứ như viết lại các khối bị lỗi hoặc bỏ qua các phần băng xấu mà không làm giảm tổng dung lượng? Hoặc có một số lý do khác cho việc hoàn thành sớm băng này?

Nếu ổ đĩa của bạn là mới và băng có chất lượng tốt, bạn có thể mong đợi có thể ghi nhiều byte vào băng hơn dung lượng chính thức. Trong một số trường hợp, bạn có thể gọi năng lực dự phòng đó, nhưng nó không được sử dụng.

Khi đầu ổ đĩa của bạn hao mòn công suất sẽ giảm. Nếu bạn kết hợp điều đó với băng có chất lượng không lớn, công suất có thể giảm hơn nữa.

Bởi vì dung lượng thay đổi như vậy, cần có một số cách để báo hiệu cho ứng dụng sao lưu của bạn rằng bạn hết dung lượng. Nó có thể là vấn đề đối với một ứng dụng sao lưu nếu nó đến cuối băng và nó không được chuẩn bị. Nó là tốt hơn cho ứng dụng với một số cảnh báo trước để nó có thể sử dụng không gian còn lại để kết thúc những gì nó đang làm.

Nếu hệ điều hành của bạn là Linux, API sẽ như vậy mà mọi writecuộc gọi hệ thống khác sẽ thất bại ENOSPCkhi bạn đạt đến phần cuối cùng của băng này. Nếu ứng dụng sao lưu của bạn không biết về tính năng này, nó sẽ coi phần đầu tiên ENOSPClà phần cuối và sẽ có một khoảng trống không sử dụng còn lại trên băng.

Tôi có thể tưởng tượng điều gì đó tương tự có thể xảy ra trên các hệ điều hành khác.

Nhờ @kasperd tôi đã thực hiện một số điều tra thêm và đây thực sự là vấn đề. Hóa ra tính năng này được gọi là EWEOM (Kết thúc cảnh báo sớm của phương tiện truyền thông) và nó đề cập đến một điểm đánh dấu được đặt trên băng bởi nhà sản xuất băng, do đó, đây không phải là ổ đĩa theo dõi lượng băng đã được lưu.

Tôi đã viết một bản vá cho mbufferchương trình tôi đang sử dụng để ghi vào băng, và chắc chắn, tại thời điểm tôi đang đến cuối băng tôi gặp ENOSPClỗi trong các write()cuộc gọi xen kẽ , nhưng tôi có thể tiếp tục viết thêm dữ liệu. Trong trường hợp của tôi, có khá nhiều dữ liệu hơn - trong khoảng từ 8 đến 19 GiB, tùy thuộc vào việc nén dữ liệu không nén được của tôi.

Điều thú vị là sau khi đạt được điểm EWEOM, tốc độ ghi băng giảm đáng kể. Nó gần như giảm một nửa từ 80MB / giây xuống còn khoảng 47MB / giây. Đây dường như không phải là vấn đề về dữ liệu vì ổ đĩa đã duy trì 80MB / giây trong nhiều giờ trước thời điểm này. Bạn có thể nghe thấy động cơ ổ đĩa chạy ở tốc độ chậm hơn và viết lại trên toàn bộ băng để phần này được viết lại không làm tăng tốc độ (vì vậy đây không phải là trường hợp ghi đầu tiên chậm hơn như lúc bắt đầu băng hoàn toàn mới.)

Tôi không thể tìm thấy bất kỳ tài liệu nào về thời điểm đánh dấu EWEOM sẽ xuất hiện trên băng, vì vậy tôi không chắc liệu nó có được chuẩn hóa hay không. Tất cả những gì tôi có thể tìm thấy là một tài liệu tham khảo mơ hồ về các ổ đĩa LTO-6/7 có tỷ lệ này tăng lên 5% không gian băng, có vẻ như rất nhiều. Có lẽ điều này là để cho phép các bộ đệm lớn được xóa do tốc độ ghi cao của băng.

Theo như API Linux, dòng có liên quan nằm trong st.c mã nguồn trình điều khiển băng SCSI và lời giải thích về hành vi này có trong sttài liệu trình điều khiển .