On Sun, Oct 24, 2004 at 10:54:43AM -0500, John Foust wrote: Shipping costs are a big concern - that's why I leaped on the one down the street at the Uni for $50 - put it in my station wagon and drove home! 120VAC. Dunno about that. I'm not even sure which one I might have. dd will handle variable block sizes on a per-tape-file basis. I'm sure there are other utilities that can as well. -ethan -- Ethan Dicks, A-130-S Current South Pole Weather at 24-Oct-2004 20:00 Z South Pole Station PSC 468 Box 400 Temp -46.7 F (-43.8 C) Windchill -64.2 F (-53.4 C) APO AP 96598 Wind 3.9 kts Grid 344 Barometer 673.1 mb (10888. ft) Ethan.Dicks(a)amanda.spole.gov http://penguincentral.com/penguincentral.html

Ethan Dicks wrote: Linux has the Unix-standard mt command, too, which allows setting the blocksize the system device uses, either explicitly or to a variable blocksize. Doc

Ethan Dicks wrote: It's amazing how much faster a DLT4000 runs when you set the blocksize to 0 (variable - allows the tape drive to set it and the app to override) instead of 512 bytes. :) Doc

Ethan Dicks wrote: Any recent Linux _should_ be doing the right thing. The only time I've actually had trouble with a DLT was the aforementioned DLT4000 on an RS/6000. AIX doesn't really believe that devices not IBM-branded can perform up to spec, and sets them to the lowest possible common spec. In this case, a hard setting of 512-byte blocksize. A mksysb backup speeded up by a factor of 30 when Jonathan coaxed the OS into using the drive's own settings. Doc

John Foust wrote: Why is because the DLTs are designed to process large chunks of data. At 512-byte blocks, it's going erk-erk-erk-erk instead of zoom. ;) I should mention that the speed of your SCSI bus might come into play here. If the DLT is attached to, say, an Adaptec 1520, there's not much lovin you can give it. Whether you need to set or reset the blocksize is dependent on the operating system and what tools you're using for writing & reading. With nearly any "modern" streamer, a variable blocksize will give the best overall performance. Doc

"Under any UNIX system"? Have you tried them all? This depends on the drive hardware and the driver. Some tape drives really do have fixed hardware block sizes. Even if setting a variable block size just causes the drive to do reblocking of some fixed on-tape block size, it still looks like a variable size block to the host. (Indeed, a classic half-inch tape can be thought of as having a fixed one-byte block size which is reblocked in hardware according to control information on the tape, though that's not a terribly useful POV.) If you are using real half-inch tapes, detecting EOT is hard. I've run into tapes with a dozen consecutive tape marks and data after them; with some hardware, if you keep reading you'll eventually run off the *physical* end of the tape - I've done it, and on the less friendly drives it's a mess to re-thread the tape enough to rewind it onto the original reel. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse(a)rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Half-inch? Are you perhaps thinking of quarter-inch? The only half-inch tapes I've ever used are the big reel-to-reel nine-track tapes, and those most definitely did not have a fixed hardware block size (except for the contrived way I sketched, looking at each byte as a record). QIC - quarter-inch cartridge - tapes did have a fixed block size, or at least most of the ones I used did. Well, it depends on the drive. QIC tapes with their serpentine recording pattern had an EOT mark on the tape that was physically different from two tape marks; the driver kept track, and when you did a second consecutive write-EOF, backed up over the previous EOF and did a write-EOT instead. Similar things were done when closing the tape, if it had been written to (or perhaps just if it was open for write). This is relevant because the drive would not read past an EOT marker, and (or so I've been told - I have no way of verifying it) the EOT marker was written not just at the current logical place (in the serpentine pattern) but at the current physical place, across the current track and all later tracks, and thus even advancing the tape by hand wouldn't buy you much. With half-inch nine-track tapes, if you overwrote the beginning of the tape, you could deliberately read past the second EOF and get whatever of the original data hadn't been overwritten (possibly with an error in the first, partial, record). Can't do that on a QIC. I think 8mm is similar to QIC in this respect, that EOT is not, on the tape, the same thing as two EOFs, and the drive will not read past an EOT marker. (Hmm, I wonder if you could "read past EOT" by overwriting the EOT and then cutting power ungracefully. I don't think I ever tried it.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse(a)rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B