Root of problem: mt seod option in Tru64 v5.x and Compaq DLT7000
tape drive lets you do something you should not be able to do --
write data after EOT !AND! leaves that EOT in place.
Normal tape format for 3 successive writes by an
application, say tar:
BOT file EOF file EOF file EOF EOF [nothing here]
--- ---
[EOT]
where
BOT=Beginning of tape, EOF=End Of File, and
EOT=End of Tape which is made up of two EOF's.
Tape positioning:
mt -f /dev/ntape/tape0c fsf n -- moves tape forward
(toward end of tape) until it has skipped n EOF's,
stopping immediately after the last one skipped.
mt -f /dev/ntape/tape0c bsf n -- moves tape backward
(toward beginning of tape) until it has skipped n
EOF's, stopping immediately after the last one
skipped; which leaves you on the BOT side of an EOF.
[an appl. read issued here will result in I/O error,
but will have left you on the EOT side of that EOF
so that an immediate follow-on read would be
successful if there were data on that side]
mt -f /dev/ntape/tape0c seod -- puts you at the 'far'
(end of tape) side of the two EOF's (EOT), not
between them! So the next write after a seod results in:
So to navigate the tape after the fact, you have to
recognize that there exist back-to-back EOF's which
will require more fsf or bsf skips than you
would otherwise expect.
e.g..,
> mt rewind
> mt -f /dev/ntape/tape0c seod
BOT file EOF file EOF file EOF EOF file EOF EOF
--- --- --- ---
leaves you here ^
after which a
> mt -f /dev/ntape/tape0c bsf 3
BOT file EOF file EOF file EOF EOF file EOF EOF
--- --- --- ---
leaves you here ^
Please send in clarifications and additional
helpful notes as follow-on to this summary,
since the above certainly does not exhaust the
the matter and only represents my understanding
of the replies from:
Lucien HERCAUD
Pat O'Brien
Mark McCann
to whom I extend much thanks. -Neil
> -----Original Message-----
> From: Neil R. Smith [mailto:neils_at_ariel.met.tamu.edu]
> Sent: Monday, June 24, 2002 6:59 PM
> To: tru64-unix-managers_at_ornl.gov
> Subject: confusing fsf, seod, tape positioning
>
>
> What does "mt -f [ntape device] seod" do?
> Experiment: Tru64 5.1A
> > mt rewind (only one tape device: a COMPAQ DLT7000)
> > tar cf /dev/ntape/tape0_d1 dir1
> > tar cf /dev/ntape/tape0_d1 dir2
> > tar cf /dev/ntape/tape0_d1 dir3
> > mt rewind
> > mt -f /dev/ntape/tape0_d1 seod
> > tar cf /dev/ntape/tape0_d1 dir4
>
> Tapex -m says there's only 3 files on the tape.
> Plus:
> > mt rewind
> > mt -f /dev/ntape/tape0_d1 fsf 3
> > tar tf /dev/ntape/tape0_d1 gives 'no data'
>
> BUT!:
> > mt rewind
> > mt -f /dev/ntape/tape0_d1 seod
> > mt -f /dev/ntape/tape0_d1 bsf 3
> > mt -f /dev/ntape/tape0_d1 fsf 1
> > tar tf /dev/ntape/tape0_d1 will read the dir4 tape archive
> AND
> > mt rewind
> > mt -f /dev/ntape/tape0_d1 seod
> > mt -f /dev/ntape/tape0_d1 bsf 5 (!?)
> > mt -f /dev/ntape/tape0_d1 fsf 1
> > tar tf /dev/ntape/tape0_d1 will read the dir3 tape archive
>
> This is maddening, at least in part because I can't seem to locate
> comprehensive documentation on EOF writes and how/when they
> are implemented by utilities like tar and vdump/vrestore. I have
> more familiarity with other unix flavors wherein each utility
> or mt 'fsf' or 'bsf' always leaves you on the end-of-tape side
> of an EOF ready to read or write.
--
Neil R. Smith, Comp. Sys. Mngr. neils_at_ariel.met.tamu.edu
Dept. Atmospheric Sci., Texas A&M Univ. 979/845-6272 FAX:979/862-4466
Received on Wed Jul 03 2002 - 23:09:15 NZST