Czy taśmy LTO mają zapasową / niewykorzystaną pojemność?

Jak rozumiem, taśmy LTO zapisują dane w „opakowaniach”, w których pierwsze owinięcie odsuwa taśmę do napędu, a drugie owinięcie z powrotem do kasety. Proces ten powtarza się wiele razy, przy założeniu, że po osiągnięciu końca taśmy cała taśma wróci do kasety i można ją wysunąć przy niewielkim przewijaniu.

Zauważyłem jednak, że kiedy dojdziesz do końca taśmy, napęd brzmi, jakby był w połowie drogi do ostatniego owinięcia, więc napęd poświęca trochę czasu na przewinięcie taśmy przed jej wysunięciem, nawet jeśli zgłosił, że koniec taśmy został osiągnięty.

Czy to dlatego, że na taśmie jest zarezerwowana pojemność, aby umożliwić takie rzeczy, jak ponowne zapisywanie nieudanych bloków lub pomijanie złych sekcji taśmy bez zmniejszania całkowitej pojemności? A może jest jakiś inny powód tego pozornie wczesnego zakończenia taśmy?

Jeśli twój napęd jest nowy, a taśma jest dobrej jakości, możesz oczekiwać, że będziesz w stanie zapisać na taśmie więcej bajtów niż oficjalna pojemność. W pewnym sensie można nazwać tę wolną pojemność, ale nie jest ona niewykorzystana.

W miarę zużycia głowic napędowych pojemność będzie się zmniejszać. Jeśli połączysz to z taśmami o niezbyt wysokiej jakości, pojemność może się jeszcze bardziej zmniejszyć.

Ponieważ pojemność różni się w ten sposób, musi istnieć jakiś sposób zasygnalizowania aplikacji do tworzenia kopii zapasowych, że brakuje jej pojemności. Może to być problematyczne w przypadku aplikacji do tworzenia kopii zapasowych, jeśli dotrze ona do końca taśmy i nie była przygotowana. Lepiej jest dla aplikacji z pewnym wyprzedzeniem, aby mogła wykorzystać pozostałą przestrzeń do podsumowania tego, co robi.

Jeśli twoim systemem operacyjnym jest Linux, API jest takie, że każde inne writewywołanie systemowe zakończy się niepowodzeniem ENOSPCpo osiągnięciu ostatniej części taśmy. Jeśli twoja aplikacja do tworzenia kopii zapasowych nie wie o tej funkcji, traktuje pierwszą ENOSPCjako koniec, a na taśmie pozostanie niewykorzystane miejsce.

Mogę sobie wyobrazić, że coś podobnego może się wydarzyć również w innym systemie operacyjnym.

Dzięki @kasperd przeprowadziłem dalsze dochodzenie i to rzeczywiście był problem. Okazuje się, że ta funkcja nazywa się EWEOM (Early Warning End of Media) i odnosi się do znacznika umieszczonego na taśmie przez producenta taśmy, więc nie jest to napęd, który śledzi, ile taśmy zostało buforowane.

Napisałem łatkę do mbufferprogramu, którego używam do zapisu na taśmie, i oczywiście w miejscu, w którym dochodziłem do końca taśmy, pojawiają się ENOSPCbłędy przy naprzemiennych write()połączeniach, ale mogę nadal zapisywać więcej danych. W moim przypadku znacznie więcej danych - między 8 a 19 GiB, w zależności od kompresji moich niezbyt ścisłych danych.

Co ciekawe, po osiągnięciu znacznika EWEOM prędkość zapisu na taśmie gwałtownie spada. Prawie zmniejsza się o połowę z 80 MB / s do około 47 MB ​​/ s. Nie wydaje się to problemem z danymi, ponieważ dysk utrzymywał prędkość 80 MB / s przez wiele godzin przed tym punktem. Słychać, jak silnik napędowy pracuje z mniejszą prędkością, a przepisywanie na całej taśmie, więc przepisanie tego fragmentu nie zwiększa prędkości (więc nie jest tak, że pierwszy zapis jest wolniejszy, jak na początku nowa taśma).

Nie mogę znaleźć żadnej dokumentacji dotyczącej tego, kiedy znacznik EWEOM powinien pojawić się na taśmie, więc nie jestem pewien, czy jest on znormalizowany. Jedyne, co mogłem znaleźć, to niejasne odniesienie do napędów LTO-6/7, które zwiększyły się do 5% miejsca na taśmie, co wydaje się dużo. Być może pozwoli to na opróżnienie dużych buforów z powodu dużej prędkości zapisu na taśmie.

Jeśli chodzi o interfejs API systemu Linux, odpowiedni wiersz znajduje się w st.c kodzie źródłowym sterownika taśmy SCSI, a wyjaśnienie tego zachowania znajduje się w stdokumentacji sterownika .