Чи мають стрічки LTO запасну / невикористану ємність?

Як я розумію, LTO-стрічки записують дані в "обгортки", де перше обгортання розкручує стрічку в привід, а друге обгортання повертає її назад в картридж. Цей процес повторюється неодноразово, при цьому ідея полягає в тому, що як тільки кінець стрічки досягнуто, вся стрічка повернеться в картридж і її можна буде витягнути з невеликим перемотуванням.

Однак я помітив, що коли ви доходите до кінця стрічки, привід звучить так, що він знаходиться приблизно на півдорозі остаточного обгортання, і тому привід витрачає деякий час на перемотування стрічки перед тим, як її вийняти, хоча він повідомив, що кінець стрічки досягнуто.

Це тому, що на стрічці є якась зарезервована ємність, щоб передбачити такі речі, як перезапис невдалих блоків або пропускати через погані ділянки стрічки, не зменшуючи загальну ємність? Або є якась інша причина цього очевидно раннього закінчення стрічки?

Якщо ваш накопичувач новий і касета хорошої якості, ви можете розраховувати, що ви зможете записати на стрічку більше байтів, ніж офіційна ємність. У певному сенсі ви можете назвати цю запасну ємність, але вона не використовується.

У міру зменшення потужності ваші приводні головки зменшаться. Якщо поєднувати це з стрічками не такої високої якості, то ємність може ще більше зменшитися.

Оскільки ємність змінюється настільки, що потрібно створити резервну копію додатку, щоб ви не мали можливості. Це може бути проблематично для програми резервного копіювання, якщо вона доходить до кінця стрічки, і вона не була підготовлена. Додаток краще з деяким попереднім попередженням, щоб воно могло використовувати решту простору для завершення роботи.

Якщо ваша ОС має бути Linux, API такий, що кожен другий writeсистемний виклик буде ENOSPCзавершений, коли ви досягнете останньої частини стрічки. Якщо ваша програма резервного копіювання не знає про цю функцію, вона вважатиметься першою ENOSPCяк кінцевою, і на стрічці залишиться небагато невикористаного місця.

Я можу уявити, що щось подібне може трапитися і в інших ОС.

Завдяки @kasperd я провів подальше розслідування, і це справді була проблема. Виявляється, ця функція називається EWEOM (Early Warning End Of Media), і вона посилається на маркер, розміщений на стрічці виробником стрічки, тому це не привід, що відстежує, скільки стрічки було заклеєно.

Я написав патч для mbufferпрограми, яку я використовую для запису на стрічку, і, напевно, в тому місці, коли я доходив до кінця стрічки, я отримую ENOSPCпомилки при чергуванні write()дзвінків, але я можу продовжувати записувати більше даних. У моєму випадку, набагато більше даних - від 8 до 19 Гб, залежно від стиснення моїх не дуже стислих даних.

Цікаво, що після досягнення маркера EWEOM швидкість запису на стрічку різко падає. Він майже вдвічі зменшується від 80 Мб / сек до приблизно 47 МБ / сек. Це, здається, не є проблемою з даними, оскільки накопичувач підтримував 80 Мб / сек за години до цього моменту. Ви можете почути привідний двигун, який працює з меншою швидкістю, і перезапис на цілій стрічці, щоб цей розділ перезаписаний не збільшував швидкість (тож справа не в тому, що перша запис може бути повільнішою, як це може бути на початку абсолютно нова стрічка.)

Я не можу знайти жодної документації про те, коли маркер EWEOM повинен з’явитися на стрічці, тому я не впевнений, чи він стандартизований. Все, що я міг знайти, - це нечітке посилання на диски LTO-6/7, які збільшувались до 5% місця стрічки, що, здається, дуже багато. Можливо, це дозволить розмити великі буфери через високу швидкість запису стрічки.

Що стосується API Linux, то відповідний рядок знаходиться у st.c вихідному коді драйвера стрічки SCSI, а пояснення такої поведінки міститься в stдокументації на драйвер .