[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