Насколько я понимаю, ленты 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% ленточного пространства, что кажется очень большим. Возможно, это сделано для того, чтобы очистить большие буферы из-за высокой скорости записи ленты.
Что касается Linux API, соответствующая строка находится в st.c Исходный код драйвера ленты SCSI и объяснение этого поведения находится в st документация по драйверу.