[PLUG] space left on tape, a "clever" idea

[Russell Senior]

>>>>> "Keith" == Keith Lofstrom <keithl at kl-ic.com> writes:

>> # mt -f /dev/nst0 setblk 32768 
>> # mt -f /dev/nst0 datcompression 2 
>> # tar -C / -b 64 -clf /dev/nst0 .  
>> # mt -f /dev/nst0 rewind 
>> # tar -C / -b 64 -dlf /dev/nst0
>> # mt -f /dev/nst0 rewind 
>> # mt -f /dev/nst0 fsf 1

Keith> Are these two commands necessary?  An nst0 (no-rewind st0) tape
Keith> device should be positioned at the end of the first record
Keith> after it was written or read.  Perhaps DDS doesn't know how to
Keith> do that...

Necessary?  Maybe not.  But safer?  Definitely.  I once (long ago when
I was writing my backup script) played with doing relative tape
movements, but found that mt and the tape drive could find themselves
in disagreement and determined that the only reliable way to establish
position (at least with these drives) was to rewind and fsf.  These
are scripted backups, running overnight, so a little extra time spent
for robust tape positioning was worth it.

>> # tar -C /aux -b 64 -clf /dev/nst0 .
>> # mt -f /dev/nst0 rewind 
>> # mt -f /dev/nst0 fsf 1

>> # tar -C /aux -b 64 -dlf /dev/nst0 
>> # mt -f /dev/nst0 rewind 
>> # mt -f /dev/nst0 fsf 2

Keith> ... and this is *why* you probably don't want to rewind, at
Keith> this point.  If you forget the fsf command, or accidentally
Keith> enter fsf 1 rather than fsf 2, you write zeros all over one of
Keith> the tars you just made.  Yikes!

My scripts never forget!

>> # mt -f /dev/nst0 datcompression 0 
>> # dd if=/dev/zero of=/dev/nst0 bs=32768 
>> dd: writing `/dev/nst0': No space left on device 
>> 34295+0 records in 
>> 34294+0 records out

Keith> Clever, yes.  But now, how do you figure how many real records
Keith> you have on the tape, next time you decide to write on that
Keith> tape?  Just assume the last record is all zeros?  Just read a
Keith> bit of each record and look for a long string of zeros, then
Keith> decide?  I suppose you could write lots of info on the tape
Keith> label.

These are just full backups, so there are only ever two real tape
files.  To determine how much slack there is on the end, you'd just:  

  # dd if=/dev/nst0 of=/dev/null bs=32768

and wait for dd to tell you how many blocks it read, or perhaps
consult the log file from the corresponding backup where this
information will already exist.

Keith> I hate tape labels, almost as much as I hate unlabelled tapes.

I am assuming you are referring to adhesive backed labels stuck onto
the exterior of the cartridge rather than some data plunked on some
portion of the tape.  I've been using these for years:

  <http://www.labelonce.com/>

Write on with ultra fine point sharpie, erase (without a trace) with a
regular white eraser and write again.

Keith> Back when I was still using tapes, the real issue was figuring
Keith> out whether an about-to-launch set of backups would *fit* on a
Keith> tape.  With compression, it was always a bit indeterminate.

Yes.  This "clever" idea doesn't totally solve the problem, but it
does provide a little bit more clue than the old "try it and see".

Keith> Tapes: Just Say No.  :-)

These are legacy backups, particularly where offsite storage in a 43.8
gram package is a desideratum.  The tape drive is a sunk cost.  Once
we exceed tape capacity, backup-to-disk will be the logical next step
in this application.


-- 
Russell Senior         ``I have nine fingers; you have ten.''
seniorr at aracnet.com