[clug] Can I re-record just the first record of a tape?

Michael James michael at james.st
Mon Jul 28 23:28:18 EST 2003


On Monday 28 July 2003 22:47, Brett Worth wrote:
> I seem to remember that an EOF mark is written twice at the end of a write
> to denote the last thing written. e.g.
>
> ------|------|------||

How does in know whether to write one or two EOF marks?
If I write multiple dumps or tars to a tape
 the writes never know if they will be the last.
And rewoffl-ing the tape is the same mt command
 that is used to eject a tape after reading, so it can't write.
The only mechanism I can think of
 would be to always finish a record by writing both marks
 then rewind and position the head just past the first.
Then if you write again, you overwrite the second.

I was hoping there was (taking an analogy with RS232)
 a sort of "syn" record that allows a ragged start to "get in step"
 ready for the start of a real record.
Rather like the hacker doing an imprecisely calculated jump
 into a string of NOPs to reach the first real instruction
 on the right byte boundary.

> When doing mt fsf sommands you are moving to the point just after the
> filemark.  Thats why you can append.  You will get an error when you try to
> read past the double file mark.  If I rewrote the above tape (even with a
> shorter block) I'd get:
>
> ------||.....|------||
>
> You'd need to convince the tape drive not to write the second EOF mark
> somehow.  You probably cant.

Or I need to convince it to write a second Start mark.

> A while ago Drake Deitrich posted a CDR backup utility which used a
> staging area to assemble enough files to fill a CDR before writing.
> If you did something like this with your tapes you could write whatever
> you liked at the start of each tape.  All you need is a bit of spare disk
> space.

Lumbers me with pre-compressing everything
 and recording on a non-compressing device,
 so I'll know in advance how much space will be used.

Maybe I'll go back to the idea of recording the log from last time.
It should give a good indication of how things will pan out.

michaelj



More information about the linux mailing list