¿Las cintas LTO tienen capacidad sobrante / no utilizada?

Según tengo entendido, las cintas LTO escriben datos en "envolturas", donde la primera envoltura desenrolla la cinta en la unidad, y la segunda envoltura la vuelve a enrollar en el cartucho. Este proceso se repite varias veces, con la idea de que una vez que se haya alcanzado el final de la cinta, toda la cinta volverá al cartucho y se puede expulsar con poco rebobinado.

Sin embargo, he notado que cuando llegas al final de una cinta, la unidad suena como si estuviera a la mitad de la envoltura final, por lo que la unidad pasa un tiempo rebobinando la cinta antes de expulsarla, a pesar de que ha informado que Se ha alcanzado el final de la cinta.

¿Es esto porque hay algo de capacidad reservada en la cinta, para permitir cosas como reescribir bloques fallidos o saltear secciones defectuosas de la cinta sin reducir la capacidad total? ¿O hay alguna otra razón para este final aparentemente temprano de la cinta?

Si su unidad es nueva y la cinta es de buena calidad, puede esperar poder escribir más bytes en la cinta que la capacidad oficial. En cierto sentido, puede llamar a esa capacidad de reserva, pero no se utiliza.

A medida que los cabezales de la unidad se desgasten, la capacidad disminuirá. Si combina eso con cintas de no tan buena calidad, la capacidad puede disminuir aún más.

Debido a que la capacidad varía de esa manera, debe haber alguna forma de indicarle a su aplicación de respaldo que no tiene capacidad. Puede ser problemático para una aplicación de respaldo si llega al final de la cinta y no está preparada. Es mejor para la aplicación con alguna advertencia previa, de modo que pueda usar el espacio restante para concluir lo que está haciendo.

Si su sistema operativo es Linux, la API es tal que cualquier otra writellamada al sistema fallará ENOSPCuna vez que llegue a esta última parte de la cinta. Si su aplicación de copia de seguridad no conoce esta característica, tratará el primero ENOSPCcomo el final, y quedará algo de espacio no utilizado en la cinta.

Me imagino que algo similar puede suceder en otros sistemas operativos también.

Gracias a @kasperd investigué un poco más y este fue el problema. Resulta que esta función se llama EWEOM (Fin de advertencia anticipada del medio) y se refiere a un marcador colocado en la cinta por el fabricante de la cinta, por lo que no es la unidad que realiza un seguimiento de la cantidad de cinta que se ha enrollado.

Escribí un parche para el mbufferprograma que estoy usando para escribir en la cinta, y efectivamente, en el punto donde estaba llegando al final de la cinta, recibo ENOSPCerrores en write()llamadas alternas , pero puedo continuar escribiendo más datos. En mi caso, muchos más datos, entre 8 y 19 GiB, dependiendo de la compresión de mis datos no muy comprimibles.

Curiosamente, después de alcanzar el marcador EWEOM, la velocidad de escritura de la cinta disminuye drásticamente. Casi se reduce a la mitad desde 80 MB / seg hasta aproximadamente 47 MB ​​/ seg. Esto no parece ser un problema de datos, ya que la unidad ha mantenido 80 MB / s durante horas antes de este punto. Puede escuchar el motor de accionamiento funcionando a una velocidad más lenta, y reescribir sobre una cinta completa para que esta sección se vuelva a escribir no aumenta la velocidad (por lo que no es un caso de que la primera escritura sea más lenta como puede ser al comienzo de un cinta nueva).

No puedo encontrar ninguna documentación sobre cuándo debería aparecer el marcador EWEOM en la cinta, por lo que no estoy seguro de si está estandarizado. Todo lo que pude encontrar es una vaga referencia a las unidades LTO-6/7, que aumentaron en un 5% del espacio de la cinta, lo que parece mucho. Tal vez esto sea para permitir que se vacíen los búferes grandes debido a la alta velocidad de escritura de la cinta.

En lo que respecta a la API de Linux, la línea relevante está en el st.c código fuente del controlador de cinta SCSI y la explicación de este comportamiento está en la stdocumentación del controlador .