13

As I understand it, LTO tapes write data in "wraps", where the first wrap unspools the tape into the drive, and the second wrap spools it back into the cartridge. This process is repeated a number of times, with the idea being that once the end of the tape has been reached, all the tape will be back in the cartridge and it can be ejected with little rewinding.

However I have noticed that when you get to the end of a tape, the drive sounds like it is about half way through the final wrap, and so the drive spends some time rewinding the tape before ejecting it, even though it has reported that the end of the tape has been reached.

Is this because there is some reserved capacity on the tape, to allow for things like rewriting failed blocks or to skip over bad sections of tape without reducing total capacity? Or is there some other reason for this apparently early finish of the tape?

Malvineous
  • 955
  • 7
  • 27

2 Answers2

13

If your drive is new and the tape is of good quality you can expect to be able to write more bytes to the tape than the official capacity. In some sense you can call that spare capacity, but it isn't unused.

As your drive heads wear down capacity will be decreasing. If you combine that with tapes of not as great quality the capacity can decrease even further.

Because capacity varies like that there need to be some way to signal to your backup application that you are out of capacity. It can be problematic for a backup application if it reaches the end of the tape and it wasn't prepared. It is better for the application with some advance warning such that it can use the remaining space to wrap up what it is doing.

If your OS happens to be Linux the API is such that every other write system call will fail with ENOSPC once you reach this last part of the tape. If your backup application doesn't know about this feature it would treat the first ENOSPC as the end, and there would be some unused space left on the tape.

I can imagine something similar can happen on other OS as well.

kasperd
  • 29,894
  • 16
  • 72
  • 122
2

Thanks to @kasperd I did some further investigation and this was indeed the problem. Turns out this feature is called the EWEOM (Early Warning End Of Media) and it refers to a marker placed on the tape by the tape manufacturer, so it is not the drive keeping track of how much tape has been spooled.

I wrote a patch for the mbuffer program I am using to write to the tape, and sure enough, at the point where I was reaching the end of the tape I get ENOSPC errors on alternating write() calls, but I can continue to write more data. In my case, quite a lot more data - between 8 and 19 GiB, depending on compression of my not-very-compressible data.

Interestingly after the EWEOM marker is reached, the tape write speed drops dramatically. It almost halves from 80MB/sec down to about 47MB/sec. This doesn't appear to be a data issue as the drive has maintained 80MB/sec for hours prior to this point. You can hear the drive motor running at a slower speed, and rewriting over a whole tape so this section gets rewritten doesn't increase the speed (so it's not a case of the first write being slower like it can be at the beginning of a brand new tape.)

I can't find any documentation about when the EWEOM marker should appear on the tape, so I'm not sure if it's standardised. All I could find is a vague reference to LTO-6/7 drives having this increased to be 5% of tape space, which seems like a lot. Perhaps this is to allow for large buffers to be flushed due to the tape's high write speed.

As far as the Linux API goes, the relevant line is in the st.c SCSI tape driver source code and the explanation of this behaviour is in the st driver documentation.

Malvineous
  • 955
  • 7
  • 27
  • The tape slows down when approaching the end to make sure it can fully stop before the physical end is reached. – Zac67 Jul 23 '17 at 09:02
  • 1
    I don't think that's the case with LTO tapes, otherwise rewinding them would go slowly as well, but rewinding a tape happens at high speed (faster than when writing) up until the last few seconds. After the EWEOM mark the drive goes slow for many minutes. So the drive definitely knows when it is near the physical start/end of the tape without needing to slow down. There must be some other cause for the reduced speed. – Malvineous Jul 23 '17 at 10:09
  • I guess the tape ends should also be protected due to the stress they are subjected to, but that's pure speculation. – Zac67 Jul 23 '17 at 11:16
  • LTO tapes aren't like traditional tapes - they never get pulled at the ends like say a cassette tape does. The only time the tape ends up completely on one spool is when the tape is ejected. Here's [a video of an LTO drive loading and ejecting a tape](https://www.youtube.com/watch?v=y-RpCzxPqac) - you'll notice two things - how much tape needs to be unwound when the eject button is pressed (it is ejected while at the beginning of the tape), and how the drive actually goes past the end of the tape during the eject but the tape simply spools back in the opposite direction - there's no hard stop. – Malvineous Jul 23 '17 at 12:01
  • The end with the leader pin and the end fastened to the reel are obviously subjected to more stress than the middle of the tape. – Zac67 Jul 23 '17 at 12:06
  • 1
    Only marginally, and only during a load/eject operation, not while the drive is reading/writing. Remember that the tape spools and unspools many times during a full beginning-to-end read or write operation, so the final write at the "end" of the tape is no different to the many reverse wraps that occurred throughout the whole operation. – Malvineous Jul 23 '17 at 12:39
  • 2
    @Zac67 If there were mechanical reasons for the drive to slow down before reaching the end you'd expect that to happen on every wrap and not just the last. – kasperd Aug 04 '17 at 22:36