As fitas LTO possuem capacidade sobressalente / não utilizada?

Question

Pelo que entendi, as fitas LTO gravam dados em "envoltórios", em que o primeiro envoltório solta a fita na unidade e o segundo envoltório a transforma de volta no cartucho. Este processo é repetido várias vezes, com a ideia de que, uma vez atingido o fim da fita, toda a fita estará de volta no cartucho e poderá ser ejetada com pouca rebobinagem.

No entanto, notei que quando você chega ao final de uma fita, a unidade soa como se estivesse na metade do final, e assim a unidade gasta algum tempo rebobinando a fita antes de ejetá-la, mesmo que tenha informou que o fim da fita foi atingido.

Isso ocorre porque existe alguma capacidade reservada na fita, para permitir coisas como reescrever blocos com falha ou pular seções ruins de fita sem reduzir a capacidade total? Ou há algum outro motivo para este aparentemente final de gravação?

    

Answer 1

Se a sua unidade for nova e a fita for de boa qualidade, você poderá escrever mais bytes na fita do que a capacidade oficial. De certa forma, você pode chamar essa capacidade extra, mas não é usada.

À medida que a capacidade de desgaste dos cabeçotes diminui, a capacidade diminui. Se você combinar isso com fitas de qualidade não tão grande, a capacidade pode diminuir ainda mais.

Como a capacidade varia, é necessário que haja alguma maneira de sinalizar ao seu aplicativo de backup que você está sem capacidade. Pode ser problemático para um aplicativo de backup se ele atingir o final da fita e não estiver preparado. É melhor para o aplicativo com algum aviso prévio, de modo que ele possa usar o espaço restante para encerrar o que está fazendo.

Se o seu sistema operacional for o Linux, a API é tal que todas as outras chamadas do sistema write falharão com ENOSPC quando você atingir essa última parte da fita. Se seu aplicativo de backup não conhecer esse recurso, ele trataria o primeiro ENOSPC como o final, e haveria algum espaço não utilizado na fita.

Eu posso imaginar que algo semelhante pode acontecer em outro sistema operacional também.

    

Answer 2

Graças a @kasperd eu fiz mais algumas investigações e este foi realmente o problema. Acontece que esse recurso é chamado de EWEOM (Early Warning End Of Media) e se refere a um marcador colocado na fita pelo fabricante da fita, por isso não é a unidade que acompanha a quantidade de fita no spool.

Eu escrevi um patch para o programa mbuffer que estou usando para gravar na fita e, com certeza, no ponto em que eu estava atingindo o final da fita, recebi ENOSPC erros ao alternar write() chamadas , mas posso continuar a escrever mais dados. No meu caso, muito mais dados - entre 8 e 19 GiB, dependendo da compressão dos meus dados não muito compressíveis.

Curiosamente, após o marcador EWEOM ser alcançado, a velocidade de gravação da fita cai drasticamente. Ele quase reduz de 80MB / seg para cerca de 47MB / seg. Isso não parece ser um problema de dados, pois a unidade mantém 80 MB / s durante horas antes desse ponto. Você pode ouvir o motor do drive rodando em uma velocidade mais lenta, e reescrever uma fita inteira para que esta seção seja reescrita não aumenta a velocidade (então não é um caso de a primeira gravação ser mais lenta como pode ser no início de uma gravação). nova fita.)

Não consigo encontrar nenhuma documentação sobre quando o marcador EWEOM deve aparecer na fita, por isso não tenho certeza se é padronizado. Tudo o que consegui encontrar é uma referência vaga às unidades LTO-6/7, que aumentaram para 5% do espaço da fita, o que parece muito. Talvez isso seja para permitir que grandes buffers sejam liberados devido à alta velocidade de gravação da fita.

No que diz respeito à API do Linux, a linha relevante está no st.c Código-fonte do driver de fita SCSI e a explicação desse comportamento está em st documentação do driver .