Jochen Kunz wrote: True, but I didn't have a basis for comparison. I'm hearing that 4MB/s is indeed slightly above par, so I guess I should be happy . -- Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/ Help our electronic games project: http://www.mobygames.com/ Or check out some trippy MindCandy at http://www.mindcandydvd.com/ A child borne of the home computer wars: http://trixter.wordpress.com/

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

e.stiebler wrote: isn't that exactly what tar's blocking factor* is supposed to do, only without the need for a separate utility? *I thought it was a standard feature of tar, not something that's only appeared since the GNU days.