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 mbuffer
programu, 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ę ENOSPC
błę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 st
dokumentacji sterownika .