Есть ли на лентах LTO резервная / неиспользованная емкость?
Насколько я понимаю, ленты LTO записывают данные в «обертках», где первая обертка разматывает ленту в накопитель, а вторая оборачивает ее обратно в картридж. Этот процесс повторяется несколько раз, при этом идея состоит в том, что как только конец ленты будет достигнут, вся лента вернется в картридж, и ее можно будет выбросить с небольшой перемоткой.
Однако я заметил, что, когда вы дойдете до конца ленты, привод звучит так, как будто прошел половину окончательного оборачивания, поэтому привод тратит некоторое время на перемотку ленты перед ее извлечением, даже если она сообщил, что достигнут конец ленты.
Это потому, что на ленте есть некоторая зарезервированная емкость для таких вещей, как перезапись неисправных блоков или пропуск поврежденных участков ленты без уменьшения общей емкости? Или есть какая-то другая причина для такого явно раннего завершения ленты?
Если ваш диск новый, а лента хорошего качества, вы можете ожидать чтобы иметь возможность записать на ленту больше байтов, чем официальная емкость. В некотором смысле вы можете назвать эту емкость резервной, но она не остается неиспользованной.
По мере износа головок дисков емкость будет уменьшаться. Если вы объедините это с лентами не столь высокого качества, емкость может уменьшиться еще больше.
Поскольку емкость изменяется таким образом, должен быть какой-то способ сообщить вашему приложению резервного копирования, что ваша емкость закончилась. Для приложения резервного копирования может возникнуть проблема, если оно достигнет конца ленты и не будет подготовлено. Для приложения лучше заранее предупредить о том, чтобы оно могло использовать оставшееся пространство для завершения того, что оно делает.
Если ваша ОС - Linux, API таков, что все остальные пишут системный вызов завершится ошибкой ENOSPC , как только вы достигнете этой последней части ленты. Если ваше приложение резервного копирования не знает об этой функции, оно будет рассматривать первый ENOSPC как конец, и на ленте останется некоторое неиспользуемое пространство.
Я могу представить, что нечто подобное может произойти с и другие ОС.
Благодаря @kasperd я провел дополнительное расследование, и это действительно была проблема. Оказывается, эта функция называется EWEOM (Early Warning End Of Media) и относится к маркеру, помещенному на ленту производителем ленты, так что это не привод, отслеживающий, сколько ленты было намотано в буфер.
I написал патч для программы mbuffer , которую я использую для записи на ленту, и, конечно же, в момент, когда я достиг конца ленты, я получаю ошибки ENOSPC при чередовании write () вызывает, но я могу продолжать писать больше данных. В моем случае данных намного больше - от 8 до 19 ГиБ, в зависимости от сжатия моих не очень сжимаемых данных.
Интересно, что после достижения маркера EWEOM скорость записи на ленту резко падает. Он почти вдвое снизился с 80 МБ / с до примерно 47 МБ / с. Это не похоже на проблему с данными, так как до этого момента диск поддерживал скорость 80 МБ / с в течение нескольких часов. Вы можете слышать, как приводной двигатель работает на более медленной скорости и перезаписывает всю ленту, поэтому перезапись этого раздела не увеличивает скорость (так что это не тот случай, когда первая запись выполняется медленнее, как это может быть в начале совершенно новая лента.)
Я не могу найти никакой документации о том, когда маркер EWEOM должен появиться на ленте, поэтому я не уверен, стандартизирован ли он. Все, что я смог найти, - это расплывчатое упоминание о накопителях LTO-6/7, у которых это увеличено до 5% от ленточного пространства, что кажется большим. Возможно, это сделано для того, чтобы очистить большие буферы из-за высокой скорости записи на ленту.
Что касается Linux API, соответствующая строка находится в исходном коде драйвера ленты SCSI st.c , и объяснение этого поведения находится в st документации драйвера .