据我了解，LTO磁带将数据写入“包装”，第一个包装将磁带放入驱动器，第二个包装将其卷回到磁带中。 这个过程重复了很多次，其思想是，一旦磁带已经到达尾部，所有的磁带将会回到磁带盒中，并且可以在退回时popup。
但是我已经注意到，当你到达磁带的末尾时，驱动器听起来像是在最后包装的一半左右，所以驱动器花费一些时间在popup磁带之前倒带，即使它已经报告磁带的末端已经到达。
这是因为磁带上有一些保留的容量，以允许重写失败的块或跳过磁带的不良部分而不减less总容量？ 还是有其他原因，这显然是磁带早期完成？
如果你的驱动器是新的，磁带质量好，你可以期望能够写入比磁带更多的字节比正式容量。 从某种意义上讲，你可以称之为剩余容量，但并不是没有使用。
由于您的磁头磨损容量将会下降。 如果把它和质量不好的磁带结合起来，容量可能会进一步下降。
由于容量不尽相同，因此需要通过某种方式向备份应用程序发出信号，说明您的容量不足。 如果备份应用程序到达磁带末尾并且没有准备好，它可能会有问题。 对于具有预先警告的应用程序来说，它可以使用剩余空间来包装它正在做的事情。
如果你的操作系统碰巧是Linux的话，那么一旦你到达磁带的最后部分，那么每一个其他的write系统调用都会因ENOSPC而失败。 如果您的备份应用程序不知道此function，则会将第一个ENOSPC视为结束，磁带上会留下一些未使用的空间。
我可以想象其他操作系统也会发生类似的情况。
感谢@ kasperd，我做了一些进一步的调查，确实是这个问题。 原来这个function被称为EWEOM（媒体预警结束），它是指磁带制造商放在磁带上的标记，所以它不是跟踪有多less磁带已被假脱机。
我为我用来写入磁带的mbuffer程序写了一个补丁，果然，在我到达磁带尾部时，交替write()调用时出现ENOSPC错误，但是我可以继续写更多的数据。 在我的情况下，有相当多的数据 – 在8和19 GiB之间，取决于我不是非常可压缩的数据的压缩。
有趣的是，在达到EWEOM标记后，磁带写入速度急剧下降。 它几乎从80MB /秒减半到47MB /秒左右。 这似乎不是一个数据问题，因为在这之前，驱动器已经维持了80MB / sec的数小时。 您可以听到驱动电机以较慢的速度运行，并在整个磁带上重写，因此该部分被重写将不会提高速度（所以不是第一次写入的速度比在第一次写入时慢全新的磁带。）
我找不到有关EWEOM标记何时出现在磁带上的任何文档，所以我不确定它是否标准化。 我所能find的仅仅是对LTO-6/7驱动器的一个模糊的参考，它增加了磁带空间的5％，这看起来很多。 也许这是为了允许由于磁带的高写入速度而使大缓冲区被刷新。
就Linux API而言，相关的行位于st.c SCSI磁带驱动程序源代码中，并且在st驱动程序文档中对此行为进行了解释。