Hi. This is both a bug report (tar-1.17 and tar-1.18) and a feature request. Background: I share SCSI tape-drives with an archive program that uses variable blocksize, so I cannot configure the tape-drives with blocksize fixed. F'rinstance
[EMAIL PROTECTED] tmp]$ mt -f /dev/st1 status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 0 bytes. Density code 0x0 (default). Soft error count since last status=0 General status bits on (45010000): BOT WR_PROT ONLINE IM_REP_EN is normal. A problem I have had is when writing GnuTar archives to this device sometimes the tape's written blocksize comes out 10240 bytes like GnuTar defaults, and sometimes it comes out 512 bytes for whatever obscure reason. Tonight I have modified my archive script to send an explicit mt -f /dev/st1 setblk 10240 after loading the tape and before kicking off tar. I'll see how that works out, but is just background and isn't really the reason I'm sharing. My problem is determining the actual blocking factor of previously written tapes. "mt -f /dev/st1 status" won't tell me this, so I am reduced to asking tar. But tar won't tell me either, so I have to guess by how fast does "tar -tvf /dev/st1". If it goes quick, then the blocking factor is 20 (GnuTar default = 10240/512 = 20 = blocking factor) and I'm good. If it goes at a crawl, then its blocking factor is 1, and if I restart using "tar --blocking-factor=1 -tvf /dev/st1" then all is also good. Some observations: 1. "tar --blocking-factor=1 -tvf /dev/st1" on a tape which is actually blocked to --blocking-factor=20 gives an error: [EMAIL PROTECTED] tapetemp]$ tar -b 1 -tvf /dev/st1 tar: /dev/st1: Cannot read: Cannot allocate memory tar: At beginning of tape, quitting now tar: Error is not recoverable: exiting now, 2. "tar -tvf /dev/st1" is supposed to issue a bad blocksize warning if the blocking factor is not 20 (or whatever the compiled default) e.g. tar: Record size = 1 block which would be fine, except the most recent version of GnuTar which actually *does* that is AFAICT tar-1.14. In particular, tar-1.17 and tar-1.18 certainly do not. 3. The GnuTar Info page suggests that giving the --read-full-records (-B) option with a blocksize larger than that used when writing will allow tar to read the archive at full speed. But that does not appear to be the case at all. Okay, so items (1) and (2) appear (to me) to be bugs, (2) perhaps being the more serious. Here are my suggested enhancements: 4. A "--report-blocking-factor" option which does no more than read the first record on the tape and report the blocking factor actually used when writing the tape. This should return the correct value regardless of whether the blocking factor is the default factor or something different. This will then allow me to write a script that will do something like #!/bin/bash BF=`tar --report-blocking-factor -f /dev/st1 | cut -d'=' -f2` sleep(10) # allow tape to rewind tar -b $BF -xf /dev/st1 depending in what output format --report-blocking-factor returns its result. 5. A "--just-read-the-tape-already" option that builds on --report-blocking-factor. I mean, if you've already determined the blocking factor used when the tape was written is not what is now expected, and determined what that blocking factor actually was, is there no reason why tar cannot just restart its read with the now-known correct blocking-factor, and get on with life? :-) I know (5) will be a bit more work, and needs to allow for the tape to re-init, but it may be something to keep in mind if you were to implement (4). (Some drives appear to do quite intelligent caching, and re-starting the read doesn't appear to incur much (if any) penalty. Others do not, and sufficient time and status-monitoring must be allowed for the tape-drive rewind. I'm a reasonable C coder and am willing to help with debug and testing. Thanks! Ed Leaver
