[Dump-users] Tape driver spanning problem -- it's back...

[Brent B. <br...@ke...>]

About a year or so ago, I found myself fighting a problem described in 
the man page for the Linux SCSI tape driver, st(4):

MT_ST_BUFFER_WRITES  (Default: true)
   Buffer all write operations in fixed-block mode.
   If this option is false and the drive uses a fixed block
   size,  then  all write operations must be for a
   multiple of the block size.  This option must be set false
   to write reliable multi-volume archives.
MT_ST_ASYNC_WRITES  (Default: true)
   When this option is true, write operations return
   immediately without waiting for the data  to  be  trans-
   ferred  to  the  drive if the data fits into the
   driver's buffer.  The write threshold determines how full
   the buffer must be before a new SCSI write command
   is issued.  Any errors reported by the  drive  will  be
   held until the next operation.  This option must
   be set false to write reliable multi-volume archives.

Basically, this is saying that you have to 'mt stclearoptions 
async-writes buffer-writes' before you start writing a multivolume tape 
set, or you're going to corrupt files at the span points between tapes. 
This had me deliriously frustrated for awhile last year until I found 
out about it, partially because it confounded me that two settings in 
the tape driver such as these which have the potential to make backups 
spanning more than one tape impossible was set to do just that BY 
DEFAULT, and partially because of the amount of research it took me to 
uncover the syntax to fix it with 'mt stclearoptions async-writes 
buffer-writes', searching for which was a jungle safari also.  (There's 
nowhere in the man pages for st(4) or mt(1) that it exactly comes right 
out with that.)

But finally, I discovered that, and tested it, and it was reliable over 
a 4-tape set.  I verified the data back, and it was good.  I think I was 
using 2.4.31 then.  (Yes, I stayed with 2.4 a long time...)

I'm now using 2.6.19.2, and using the same exact tape drive, and it 
appears that sometime between then and now, the maintainers of the tape 
driver 'st' have done something to once again make spanning multiple 
volumes difficult or impossible.  The very same 4-volume set, read with 
the very same tape driver settings, on the same tape drive, now yields 
familiar errors about "Missing blocks at the end of ..., assuming hole", 
"resync restore, skipped 321 blocks", "expected next file 3698222, got 
0", and so on, every time a new tape is mounted during the multivolume 
restore.  That is exactly what it used to do for files at the span point 
of every tape change when you *didn't* take care to 'mt stclearoptions 
async-writes buffer-writes' beforehand.  Now it does that regardless.

I know this is really more of a tape driver problem than a dump problem, 
but the Linux SCSI tape list is practically dead -- even spam doesn't 
live there anymore, so I thought this might be a better place to ask, 
especially since I use dump almost exclusively for backups.

-- 
+ Brent A. Busby	 +  "...the killer application for Windows was Visual
+ UNIX Systems Admin	 +  Basic.  It allowed you to make your hokey, self-
+ University of Chicago	 +  made applications that did something stupid for
+ James Franck Institute +  your enterprise."	--Linus Torvalds