[Bug-tar] Bad-blocksize not being reported

[Ed Leaver]

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

address@hidden 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:
address@hidden 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