General SCSI+DLT speed questions

On 14 May 2007 at 6:24, Tim Shoppa wrote: Generally, we disabled compression on our applications--we decided it was better to move more tape and keep it moving rather than risking shoeshining with compression. Tape (per megabyte) was comparatively cheap. Which brings up another aspect of the difference between high-end drives such as DLT and the cheap floppy-tape QIC units that cost an order of magnitude less. DLTs/8mm/DDS drives by and large had considerable internal buffering--at least a half-meg and usually more. If you did anything outside of write-after-write type operation, the buffering algorithms could make things seem a little odd. For example, we wrote a volume catalog at the start of each tape (and later updated it after EOT was hit). My initial approach was to simply write the catalog and then read it back to make sure that everything got out to tape correctly. Of course, there was absolutely no tape motion--I was spinning my wheels by writing to and reading from the drive buffer. IIRC, the SCSI spec states that if there's a write pending and there's a change of direction, that pending writes are flushed. It was surprising to witness the number of manufacturers who didn't hew to the spec. Usually, writing a tapemark and then rewinding succeeded in forcing the data to tape, but one or two vendors got a phone call when not even that happened. Similarly, you'd think that write-after-read rules would be universally observed, since they were also called out in the spec. Such was not always the case. I think this is part of the reason why some people talk about "SCSI voodoo"--device firmware didn't always follow the rules. BTW, did you know that the folks at Exabyte were granted a 1997 software patent on the notion of a physical drive backup? I'm not aware that they ever bothered to litigate on the basis of the patent-- there was a ton of prior art that probably wouldn't allow their patent to stand. Cheers, Chuck