Les bandes LTO ont-elles une capacité disponible / inutilisée?

Si je comprends bien, les bandes LTO écrivent les données dans des «enveloppements», où le premier enveloppement débobine la bande dans le lecteur et le second enroulage les remet dans la cartouche. Ce processus est répété plusieurs fois, l'idée étant qu'une fois la fin de la bande atteinte, toute la bande sera de retour dans la cartouche et elle pourra être éjectée avec peu de rembobinage.

Cependant, j'ai remarqué que lorsque vous arrivez à la fin d'une bande, le lecteur sonne comme s'il était à mi-chemin de l'habillage final.Le lecteur passe donc un peu de temps à rembobiner la bande avant de l'éjecter, même s'il a signalé que le la fin de la bande est atteinte.

Est-ce parce qu'il y a une certaine capacité réservée sur la bande, pour permettre des choses comme la réécriture de blocs ayant échoué ou pour sauter les mauvaises sections de la bande sans réduire la capacité totale? Ou y a-t-il une autre raison à cette finition apparemment précoce de la bande?

Si votre lecteur est neuf et que la bande est de bonne qualité, vous pouvez vous attendre à pouvoir écrire plus d'octets sur la bande que la capacité officielle. Dans un certain sens, vous pouvez appeler cette capacité de réserve, mais elle n'est pas inutilisée.

À mesure que vos têtes d'entraînement s'usent, la capacité diminue. Si vous combinez cela avec des bandes de moins bonne qualité, la capacité peut encore diminuer.

Parce que la capacité varie comme ça, il doit y avoir un moyen de signaler à votre application de sauvegarde que vous êtes à court de capacité. Cela peut être problématique pour une application de sauvegarde si elle atteint la fin de la bande et qu'elle n'a pas été préparée. Il est préférable pour l'application avec un avertissement préalable de sorte qu'elle puisse utiliser l'espace restant pour conclure ce qu'elle fait.

Si votre système d'exploitation est Linux, l'API est telle que tous les autres writeappels système échoueront ENOSPCune fois que vous aurez atteint cette dernière partie de la bande. Si votre application de sauvegarde ne connaît pas cette fonctionnalité, elle traitera la première ENOSPCcomme la fin et il restera de l'espace inutilisé sur la bande.

Je peux imaginer que quelque chose de similaire peut également se produire sur d'autres systèmes d'exploitation.

Grâce à @kasperd, j'ai fait une enquête plus approfondie et c'était effectivement le problème. Il s'avère que cette fonctionnalité est appelée EWEOM (Early Warning End Of Media) et fait référence à un marqueur placé sur la bande par le fabricant de la bande, il ne s'agit donc pas du lecteur qui garde la trace de la quantité de bande mise en file d'attente.

J'ai écrit un correctif pour le mbufferprogramme que j'utilise pour écrire sur la bande, et bien sûr, au point où j'arrivais à la fin de la bande, j'obtiens des ENOSPCerreurs sur les write()appels alternés , mais je peux continuer à écrire plus de données. Dans mon cas, beaucoup plus de données - entre 8 et 19 Gio, en fonction de la compression de mes données peu compressibles.

Fait intéressant, une fois le marqueur EWEOM atteint, la vitesse d'écriture sur bande diminue considérablement. Il diminue de moitié, passant de 80 Mo / s à environ 47 Mo / s. Cela ne semble pas être un problème de données car le lecteur a maintenu 80 Mo / s pendant des heures avant ce point. Vous pouvez entendre le moteur d'entraînement tourner à une vitesse plus lente, et réécrire sur une bande entière afin que cette section soit réécrite n'augmente pas la vitesse (donc ce n'est pas le cas de la première écriture étant plus lente comme elle peut l'être au début d'un toute nouvelle bande.)

Je ne trouve aucune documentation sur le moment où le marqueur EWEOM doit apparaître sur la bande, donc je ne sais pas s'il est normalisé. Tout ce que j'ai pu trouver est une vague référence aux lecteurs LTO-6/7 ayant augmenté de 5% de l'espace sur bande, ce qui semble beaucoup. Il s'agit peut-être de permettre le vidage de grands tampons en raison de la vitesse d'écriture élevée de la bande.

En ce qui concerne l'API Linux, la ligne appropriée se trouve dans le st.c code source du pilote de bande SCSI et l'explication de ce comportement se trouve dans la stdocumentation du pilote .