I nastri LTO hanno capacità di riserva / non utilizzata?

A quanto ho capito, i nastri LTO scrivono i dati in "involucri", in cui il primo involucro annulla il nastro nell'unità e il secondo avvolgimento lo riavvolge nella cartuccia. Questo processo viene ripetuto più volte, con l'idea che una volta raggiunta la fine del nastro, tutto il nastro tornerà nella cartuccia e può essere espulso con un piccolo riavvolgimento.

Tuttavia, ho notato che quando si arriva alla fine di un nastro, l'unità suona come se fosse circa a metà dell'involucro finale e quindi l'unità impiega un po 'di tempo a riavvolgere il nastro prima di espellerlo, anche se ha riferito che il è stata raggiunta la fine del nastro.

Questo perché sul nastro è presente una capacità riservata, per consentire la riscrittura di blocchi non riusciti o per saltare sezioni danneggiate del nastro senza ridurre la capacità totale? O c'è qualche altra ragione per questa finitura apparentemente precoce del nastro?

Se l'unità è nuova e il nastro è di buona qualità, ci si può aspettare di poter scrivere più byte sul nastro rispetto alla capacità ufficiale. In un certo senso puoi chiamare quella capacità inutilizzata, ma non è inutilizzata.

Man mano che le testine si consumano, la capacità diminuirà. Se lo si combina con nastri di qualità non altrettanto elevata, la capacità può diminuire ulteriormente.

Poiché la capacità varia in questo modo, è necessario che ci sia un modo per segnalare all'applicazione di backup che non si dispone della capacità. Può essere problematico per un'applicazione di backup se raggiunge la fine del nastro e non è stato preparato. È meglio per l'applicazione con qualche avvertimento in anticipo in modo che possa usare lo spazio rimanente per concludere ciò che sta facendo.

Se il tuo sistema operativo è Linux, l'API è tale che ogni altra writechiamata di sistema fallirà ENOSPCuna volta raggiunta quest'ultima parte del nastro. Se l'applicazione di backup non è a conoscenza di questa funzionalità, considererebbe la prima ENOSPCcome la fine e sul nastro rimarrebbe uno spazio inutilizzato.

Posso immaginare che qualcosa di simile possa accadere anche su altri sistemi operativi.

Grazie a @kasperd ho fatto ulteriori indagini e questo era davvero il problema. Si scopre che questa funzione è chiamata EWEOM (Early Warning End Of Media) e si riferisce a un marcatore posizionato sul nastro dal produttore del nastro, quindi non è l'unità che tiene traccia della quantità di nastro che è stato inviato in spool.

Ho scritto una patch per il mbufferprogramma che sto usando per scrivere sul nastro, e abbastanza sicuro, nel punto in cui stavo raggiungendo la fine del nastro ricevo ENOSPCerrori su write()chiamate alternate , ma posso continuare a scrivere più dati. Nel mio caso, molti più dati, tra 8 e 19 GiB, a seconda della compressione dei miei dati non molto comprimibili.

È interessante notare che dopo aver raggiunto il marker EWEOM, la velocità di scrittura del nastro diminuisce drasticamente. Dimezza quasi da 80 MB / sec fino a circa 47 MB ​​/ sec. Questo non sembra essere un problema di dati poiché l'unità ha mantenuto 80 MB / sec per ore prima di questo punto. È possibile ascoltare il motore dell'unità a una velocità inferiore e riscrivere su un intero nastro in modo che questa sezione venga riscritta non aumenti la velocità (quindi non è un caso in cui la prima scrittura sia più lenta come potrebbe essere all'inizio di un nastro nuovo di zecca.)

Non riesco a trovare alcuna documentazione su quando il marker EWEOM dovrebbe apparire sul nastro, quindi non sono sicuro che sia standardizzato. Tutto quello che ho potuto trovare è un vago riferimento alle unità LTO-6/7 con un aumento del 5% dello spazio su nastro, che sembra molto. Forse questo per consentire lo svuotamento di buffer di grandi dimensioni a causa dell'elevata velocità di scrittura del nastro.

Per quanto riguarda l'API di Linux, la riga pertinente si trova nel st.c codice sorgente del driver del nastro SCSI e la spiegazione di questo comportamento è nella stdocumentazione del driver .