As fitas LTO têm capacidade sobressalente / não utilizada?

Pelo que entendi, as fitas LTO gravam dados em "envolvimentos", onde o primeiro invólucro desenrola a fita na unidade e o segundo enrola em spool de volta no cartucho. Esse processo é repetido várias vezes, com a ideia de que, uma vez atingido o final da fita, toda a fita voltará ao cartucho e poderá ser ejetada com pouca rebobinagem.

No entanto, notei que, quando você chega ao final de uma fita, a unidade parece estar na metade do envoltório final e, portanto, passa algum tempo rebobinando a fita antes de ejetar, mesmo que tenha relatado que o o fim da fita foi atingido.

Isso ocorre porque há alguma capacidade reservada na fita, para permitir coisas como reescrever blocos com falha ou pular seções ruins da fita sem reduzir a capacidade total? Ou há alguma outra razão para esse acabamento aparentemente precoce da fita?

Se sua unidade for nova e a fita tiver boa qualidade, você poderá gravar mais bytes na fita do que a capacidade oficial. Em certo sentido, você pode chamar isso de capacidade não utilizada, mas não é utilizada.

À medida que as cabeças de acionamento se desgastam, a capacidade diminui. Se você combinar isso com fitas de qualidade não tão boa, a capacidade poderá diminuir ainda mais.

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

Se o seu sistema operacional for Linux, a API é tal que todas as outras writechamadas do sistema falharão ENOSPCassim que você chegar a essa última parte da fita. Se o seu aplicativo de backup não souber sobre esse recurso, ele tratará o primeiro ENOSPCcomo o final e restará algum espaço não utilizado na fita.

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

Graças a @kasperd, fiz uma investigação mais aprofundada e esse foi realmente o problema. Acontece que esse recurso é chamado de EWEOM (Fim da mídia de aviso prévio) e se refere a um marcador colocado na fita pelo fabricante da fita; portanto, não é a unidade que monitora a quantidade de fita que foi colocada no spool.

Eu escrevi um patch para o mbufferprograma que estou usando para gravar na fita e, com certeza, no ponto em que estava chegando ao final da fita, recebo ENOSPCerros em write()chamadas alternadas , mas posso continuar escrevendo mais dados. No meu caso, muito mais dados - entre 8 e 19 GiB, dependendo da compactação dos meus dados não muito compactáveis.

Curiosamente, depois que o marcador EWEOM é alcançado, a velocidade de gravação da fita cai drasticamente. Quase reduz pela metade de 80 MB / s para 47 MB ​​/ s. Isso não parece ser um problema de dados, pois a unidade manteve 80 MB / s por horas antes deste ponto. Você pode ouvir o motor de acionamento a uma velocidade mais lenta e reescrever uma fita inteira, para que esta seção seja reescrita para não aumentar a velocidade (portanto, não é o caso da primeira gravação ser mais lenta, como pode ser no início de uma fita nova.)

Não consigo encontrar nenhuma documentação sobre quando o marcador EWEOM deve aparecer na fita, portanto, não tenho certeza se ele está padronizado. Tudo o que pude encontrar é uma referência vaga às unidades LTO-6/7, que aumentaram para 5% do espaço da fita, o que parece muito. Talvez 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á na stdocumentação do driver .