Glad you brought up this "feature" Nathan. I had heard it before but not using tape, promptly forgot it.
Jon On Thu, May 14, 2020 at 05:30:53PM -0400, Nathan Stratton Treadway wrote: > On Thu, May 14, 2020 at 09:14:17 +0200, Stefan G. Weichinger wrote: > > Interesting, how can a "dirty" drive trigger this behavior? > > > > I'd expect failures all along and not after ~200 or 300 GB written. > > > > I don't see any interrupted writing or so (until that End Of Tape). > > > (We switched to disk-drive vtapes a long time ago so when I was last > looking into the details of backup-tape-drive behavior it was probably > for pre-LTO technology, but I would assume that for this discussion LTO > is similar....) > > For "modern" error-correcting tape drives, when the computer sends data > out to the tape drive to be written to tape, the drive actually then > uses the read head to immedately read back in the data it just wrote. > If that read fails, the drive will automatically/transparently try the > write again... repeating the process until it is able to achieve a > successful confirmation read of that block of data. > > Normally this just happens once in a while, when there's a bad spot on > the tape or some fluke of writing makes the data unreadable, and one > doesn't even notice it's happening. > > However, if the drive head is dirty or the tape media in general is > wearing out, then what happens is that many many many of the data blocks > either will be written badly or will fail to read back in [depending on > what exactly is dirty or failing], and the drive will have to re-write > data multiple times before a succesful write/read cycle. > > When that happens, then lots of the linear space on the tape is used by > all the repeated writes -- thus making the tape appear to have a lower > capacity than you would expect -- and also all that re-writing means the > data throughput from the server's point of view is much reduced. > > (Note that in this scenario the drive just keeps retrying to write a > block up data until it succeeds... or until it hits the end of the tape. > So that's why you don't get "interrupted writing" in the sense of having > mid-tape write errors returned by the tape device the computer. [But it > is "interrupted" in the sense that a block takes much longer to write > than it should so the computer has to wait a long time before it can > sent the next block of data down to the drive.]) > > Hope that makes sense. > > Nathan > > ---------------------------------------------------------------------------- > Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region > Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ > GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 > Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 >>> End of included message <<< -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
