据我了解，LTO 磁带将数据写入“包裹”中，其中第一个包裹将磁带解绕到驱动器中，第二个包裹将其绕回磁带盒中。这个过程会重复多次，其想法是，一旦到达磁带的末端，所有的磁带都将重新回到磁带盒中，并且几乎不需要倒带就可以将其弹出。
但是我注意到，当您到达磁带的末尾时，驱动器听起来好像是最后一圈的一半，因此驱动器在弹出磁带之前会花一些时间倒带，即使它报告说已到达磁带的末尾。
这是因为磁带上有一些保留容量，以允许诸如重写失败的块或跳过磁带的坏部分而不减少总容量之类的事情吗？还是有其他原因导致磁带明显提前完成？
如果您的驱动器是新的并且磁带质量很好，您可以预期能够向磁带写入比官方容量更多的字节。从某种意义上说，您可以称其为备用容量，但它并没有被使用。
随着您的驱动头磨损，容量将减少。如果将其与质量不高的磁带结合起来，容量可能会进一步下降。
由于容量变化如此之大，因此需要某种方式向您的备份应用程序发出容量不足的信号。如果备份应用程序到达磁带的末尾并且没有准备好，它可能会出现问题。对于应用程序来说，最好有一些预先警告，这样它就可以使用剩余的空间来完成它正在做的事情。
如果您的操作系统恰好是 Linux，那么一旦您到达磁带的最后一部分， API 就会导致所有其他
write系统调用都失败。ENOSPC如果您的备份应用程序不知道此功能，它会将第一个ENOSPC视为结束，并且磁带上会留下一些未使用的空间。我可以想象在其他操作系统上也会发生类似的事情。
感谢@kasperd，我做了一些进一步的调查，这确实是问题所在。事实证明，此功能称为 EWEOM（媒体提前警告结束），它指的是磁带制造商在磁带上放置的标记，因此它不是驱动器跟踪已假脱机的磁带数量。
我为我用来写入磁带的程序编写了一个补丁
mbuffer，果然，在我到达磁带末尾的时候，我ENOSPC在交替write()调用时遇到错误，但我可以继续写入更多数据。在我的情况下，更多的数据 - 8 到 19 GiB 之间，这取决于我对不太可压缩的数据的压缩。有趣的是，达到 EWEOM 标记后，磁带写入速度急剧下降。它几乎从 80MB/秒减半到大约 47MB/秒。这似乎不是数据问题，因为驱动器在此之前的几个小时内一直保持 80MB/秒。您可以听到驱动电机以较慢的速度运行，并且在整个磁带上重写，因此这部分被重写并不会提高速度（所以这不是第一次写入速度较慢的情况，就像它可以在开始时一样全新胶带。）
我找不到任何关于 EWEOM 标记何时出现在磁带上的文档，所以我不确定它是否标准化。我所能找到的只是对 LTO-6/7 驱动器的模糊引用，它增加到磁带空间的 5%，这似乎很多。由于磁带的高写入速度，这可能是为了允许刷新大缓冲区。
就 Linux API 而言，相关行在
st.cSCSI 磁带驱动程序源代码中，对此行为的解释在st驱动程序文档中。