LTO磁带是否有备用/未使用的容量?


13

据我了解,LTO磁带以“包装”形式写入数据,其中第一个包装将磁带解绕到驱动器中,而第二个包装将其绕回到磁带中。此过程重复了很多次,其想法是,一旦到达磁带的末端,所有的磁带将重新回到盒带中,并且几乎不需倒带就可以弹出。

但是,我注意到,当您到达磁带末端时,驱动器听起来好像已经完成了最后一卷的一半,因此驱动器会花一些时间在倒带之前将其倒带,即使它报告磁带的末端已到达。

这是因为磁带上有一些保留的容量,以便允许在不减少总容量的情况下重写失败的块或跳过磁带的坏部分之类的事情吗?还是磁带似乎早日完成了其他原因?

Answers:


13

如果您的驱动器是新驱动器且磁带质量良好,则可以期望向磁带中写入的字节数超出了官方容量。从某种意义上讲,您可以调用该备用容量,但它并未被使用。

随着驱动器磁头的磨损,容量将会减少。如果将其与质量不高的磁带结合使用,容量可能会进一步下降。

由于容量会像这样变化,因此需要某种方式向备份应用程序发出信号,告知您容量不足。如果备份应用程序到达了磁带的末端并且没有准备好,则可能会出现问题。最好使用一些预先警告的应用程序,以便它可以使用剩余空间来包装正在执行的操作。

如果您的操作系统恰好是Linux,那么一旦到达磁带的最后一部分,该API就会使所有其他write系统调用均会失败ENOSPC。如果您的备份应用程序不知道此功能,它将处理第一个ENOSPC当作结尾,并且磁带上还会有一些未使用的空间。

我可以想象在其他操作系统上也会发生类似的情况。


2

感谢@kasperd,我做了进一步的调查,这确实是问题所在。事实证明,此功能称为EWEOM(介质提前警告),它是指磁带制造商在磁带上放置的标记,因此它不是驱动器跟踪已卷取多少磁带。

我为mbuffer要用于写入磁带的程序编写了一个补丁,可以肯定的是,在到达磁带末端时,ENOSPC交替write()调用会 出错,但是我可以继续写入更多数据。就我而言,取决于我的压缩率不是很高的数据,还有更多的数据-8到19 GiB之间。

有趣的是,达到EWEOM标记后,磁带写入速度急剧下降。它几乎从80MB /秒减少到47MB /秒。这似乎不是数据问题,因为在此之前,驱动器已保持80MB / sec的速度。您会听到驱动电机的运行速度较慢,并且在整个磁带上进行重写,因此重写此部分不会提高速度(因此,这不是第一次写入速度较慢的情况,就像磁带开始时那样)。全新磁带。)

我找不到有关EWEOM标记何时应出现在磁带上的任何文档,因此我不确定它是否已标准化。我所能找到的是对LTO-6 / 7驱动器的模糊引用,该驱动器已增加到磁带空间的5%,这似乎很多。由于磁带的高写入速度,这可能是为了允许清除较大的缓冲区。

就Linux API而言,相关行在st.c SCSI磁带驱动程序源代码中,而有关此行为的说明在st驱动程序文档中


磁带在接近末端时会放慢速度,以确保在达到物理末端之前可以完全停止。
Zac67

1
我认为LTO磁带不是这种情况,否则倒带也会缓慢,但是倒带会一直高速(比写入时快)直到最后几秒钟。在EWEOM标记后,驱动器会慢许多分钟。因此,驱动器肯定会知道它何时靠近磁带的物理起点/终点,而无需降低速度。速度降低一定还有其他原因。
Malvineous

我猜磁带的末端也应该受到保护,因为它们要承受压力,但这纯粹是推测。
Zac67

1
仅在驱动器读/写时略有限制,并且仅在加载/弹出操作过程中。请记住,在一次完整的从头到尾的读取或写入操作中,磁带会多次上线和下线,因此,在磁带“末尾”进行的最终写入与整个操作中发生的许多反向回绕没有什么不同。
Malvineous

2
@ Zac67如果由于机械原因导致驱动器在到达末尾之前减速,那么您会希望这种情况不仅发生在最后一次,而且还会发生在每次缠绕中。
卡巴斯德(Kasperd)'17年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.