[1296] in linux-scsi channel archive

home help back first fref pref prev next nref lref last post

Re: SCSI tape control - and some other bits

daemon@ATHENA.MIT.EDU (Andy Poling)
Thu Jan 23 12:05:47 1997

Date: 	Thu, 23 Jan 1997 02:55:45 -0500 (EST)
From: Andy Poling <andy@realbig.com>
To: Matt Swanson <matts@ozemail.com.au>
cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <32e55f5c.1454951@mail.ozemail.com.au>

On Wed, 22 Jan 1997, Matt Swanson wrote:
[...]
> 3) Last (but I'm sure not least) I have familiarised myself with the
> tar and mt commands but cannot get my tape unit to append to an
> existing tar file on the tape. Considering the TR4 is 4gb native and
> 8bg compressed (2:1 ha ha) it seems a waste of tape if I can't append.
> I have started writing my own backup/restore scripts but have become
> stumped with the SCSI tape control required for this operation. 

Welcome to UNIX (er, Linux too) tape hell.

AFAIK you cannot append to a tape file.  The driver insists on writing a
tape mark when you close the device, and if you manage to get the tape
positioned before the tape mark before writing (hint: mt bsf) I'm pretty
sure that a tape mark will still somehow get between the old data and the
new data.

I've never managed to pull it off, but then again I didn't try too hard once
I thought about waht I was doing.

At this point, I put on my best wisened look and tell you that it's a bad
idea anyhow.  In trying to append to an existent tape file, you risk
damaging it, or confusing whatever tries to read it later.  You're better
off putting your additional tar output in the next tape file and just
reading it after the first one when the time comes to read.

> I am
> using /dev/nst0 so the tape should not rewind.

That's true, but it did write a tape mark when you closed the device, so
you'll now start writing the next tape file.

-Andy

Global Auctions


home help back first fref pref prev next nref lref last post