Ленты LTO имеют запасную / неиспользованную емкость?

Насколько я понимаю, ленты LTO записывают данные в «обертках», где первая обертка отматывает ленту в накопитель, а вторая обмотка возвращает ее обратно в картридж. Этот процесс повторяется несколько раз, и идея заключается в том, что, как только будет достигнут конец ленты, вся лента снова окажется в картридже, и ее можно будет извлечь с небольшой перемоткой.

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

Это связано с тем, что на ленте есть некоторая зарезервированная емкость, позволяющая перезаписывать отказавшие блоки или пропускать поврежденные участки ленты без уменьшения общей емкости? Или есть какая-то другая причина для этого очевидно раннего конца ленты?

Если ваш диск новый и лента хорошего качества, вы можете ожидать, что сможете записать на ленту больше байтов, чем официальная емкость. В некотором смысле вы можете назвать эту свободную емкость, но она не используется.

По мере износа головок вашего привода будет уменьшаться. Если вы объедините это с лентами не такого высокого качества, емкость может уменьшиться еще больше.

Поскольку емкость варьируется таким образом, должен быть какой-то способ сообщить вашему приложению резервного копирования о том, что у вас недостаточно ресурсов. Это может быть проблематично для приложения резервного копирования, если оно достигает конца ленты и не было подготовлено. Лучше для приложения с некоторым предварительным предупреждением, чтобы оно могло использовать оставшееся пространство, чтобы завершить то, что оно делает.

Если ваша операционная система Linux, то API таков, что любой другой writeсистемный вызов завершится неудачно, как ENOSPCтолько вы достигнете этой последней части ленты. Если ваше приложение резервного копирования не знает об этой функции, оно будет рассматривать первое ENOSPCкак конец, и на ленте останется неиспользованное пространство.

Я могу представить, что нечто подобное может произойти и на других ОС.

Благодаря @kasperd я провел дополнительное расследование, и это действительно было проблемой. Оказывается, эта функция называется EWEOM (конец носителя с ранним предупреждением) и относится к маркеру, размещенному на ленте изготовителем ленты, поэтому она не отслеживает, сколько ленты было помещено в буфер.

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

Интересно, что после достижения маркера EWEOM скорость записи на ленту резко падает. Он почти вдвое сокращается с 80 МБ / с до примерно 47 МБ / с. Похоже, это не проблема с данными, поскольку накопитель поддерживал скорость 80 МБ / с в течение нескольких часов до этой точки. Вы можете услышать, что приводной двигатель работает на более медленной скорости, и перезапись по всей ленте, так что этот раздел перезаписывается, не увеличивает скорость (поэтому это не тот случай, когда первая запись медленнее, чем это может быть в начале новенькая лента.)

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

Что касается Linux API, соответствующая строка находится в st.c исходном коде драйвера ленты SCSI, а объяснение этого поведения - в stдокументации драйвера .