LTO bantların yedek / kullanılmayan kapasitesi var mı?

Anladığım kadarıyla, LTO bantları "sargı" biçiminde veri yazar, burada birinci sargı bandı sürücüye ayırır ve ikinci sargı tekrar kartuşa biriktirir. Bu işlem, bandın sonuna ulaşıldığında, tüm bandın kartuşa geri döneceği ve az geri sarma ile çıkarılabileceği düşüncesiyle birkaç kez tekrarlanır.

Bununla birlikte, bir bandın sonuna geldiğinizde, sürücünün son sargının yaklaşık yarısında olduğu gibi geldiğini fark ettim ve bu nedenle, sürücünün, bandı çıkarmadan önce bandı geri sarmak için biraz zaman harcadığını, bandın sonuna ulaşıldı.

Bunun nedeni, bantta, başarısız blokları yeniden yazmak gibi şeylere izin vermek veya toplam kapasiteyi düşürmeden kasetin kötü bölümlerini atlamak gibi bazı ayrılmış kapasiteler olduğu için mi? Yoksa bandın bu erken bitirmesinin başka bir nedeni var mı?

Sürücünüz yeni ve kaset iyi kalitede ise, kasete resmi kapasiteden daha fazla bayt yazmayı bekleyebilirsiniz. Bir anlamda bu yedek kapasiteyi arayabilirsiniz, ancak kullanılmaz.

Tahrik kafalarınız aşınma kapasitesi düşeceğinden. Bunu çok kaliteli olmayan bantlarla birleştirirseniz, kapasite daha da düşebilir.

Kapasite bu şekilde değiştiğinden, yedekleme uygulamanıza kapasite dışında olduğunuzu bildirmenin bir yolu olması gerekir. Yedekleme uygulaması için, bandın sonuna ulaşırsa ve hazır değilse sorun yaratabilir. Uygulamanın, yaptığı işi sarmak için kalan alanı kullanabilmesi için önceden uyarı ile daha iyidir.

İşletim sisteminiz Linux oluyorsa, API, kasetin bu son bölümüne ulaştığınızda diğer tüm writesistem çağrılarının başarısız olacağı şekildedir ENOSPC. Yedek uygulamanız bu özelliği bilmiyorsa, ilkini ENOSPCson olarak kabul eder ve kasette kullanılmayan bir alan kalır .

Benzer bir şeyin diğer işletim sistemlerinde de olabileceğini hayal edebiliyorum.

@Kasperd sayesinde daha fazla araştırma yaptım ve bu gerçekten problemdi. Bu özelliğe EWEOM (Ortamın Erken Uyarı Sonu) denir ve bant üreticisi tarafından kasete yerleştirilen bir işaretçiyi ifade eder, bu nedenle bantın ne kadar biriktirildiğini takip eden sürücü değildir.

mbufferKasete yazmak için kullandığım program için bir yama yazdım ve kasetin sonuna ulaştığım noktada ENOSPC, alternatif write()aramalarda hatalar alıyorum, ancak daha fazla veri yazmaya devam edebilirim. Benim durumumda, çok daha fazla veri - çok sıkıştırılamayan verilerimin sıkıştırılmasına bağlı olarak 8 ile 19 GiB arasında.

İlginçtir ki, EWEOM işaretine ulaşıldıktan sonra, kaset yazma hızı önemli ölçüde düşer. Neredeyse 80MB / sn'den yaklaşık 47MB / sn'ye kadar yarıya iner. Sürücü bu noktadan önceki saatlerde 80MB / sn'yi koruduğu için bu bir veri sorunu gibi görünmüyor. Tahrik motorunun daha düşük bir hızda çalıştığını duyabilir ve tüm bant üzerinden yeniden yazabilirsiniz, böylece bu bölüm yeniden yazılır, hızı arttırmaz (bu nedenle, ilk yazma işleminin başlangıcındaki gibi daha yavaş olması bir durum değildir yeni bant.)

EWEOM işaretçisinin bantta ne zaman görünmesi gerektiği hakkında herhangi bir belge bulamıyorum, bu yüzden standart olup olmadığından emin değilim. Bulabildiğim tek şey, LTO-6/7 sürücülerine belirsiz bir referanstır, bu da bant alanının% 5'i kadar arttı, ki bu çok gibi görünüyor. Belki de bu, bandın yüksek yazma hızı nedeniyle büyük arabelleklerin temizlenmesine izin vermektir.

Linux API'sine gelince, ilgili satır st.c SCSI teyp sürücüsü kaynak kodundadır ve bu davranışın açıklaması stsürücü belgelerinde yer almaktadır .