View Single Post
  #11  
Old September 4th 03, 07:01 AM
Rob Turk
external usenet poster
 
Posts: n/a
Default

"Paul Rubin" wrote in message
...
Malcolm Weir writes:
Still, what you've experienced shows the benefit of writing lots of
file marks. Classic Unix (and Unix-like) things (tar, etc.) want to
write *one* tape file, and if part of that file is corrupted, then
it's all lost. But if you write a filemark every (say) 100MB, then
the chances of being able to seek past the bad spot improve
dramatically.


I've heard that if you write two consecutive EOF marks on a DDS or 8mm
tape, that's interpreted as end-of-tape and there's absolutely no way
to read past it. It's not like the old days of 9 track tape.


One more example of half-truth. Filemarks are logical entities on tape, just
like data blocks are. Reading past two filemarks is just as well possible as
reading past any other data entity on tape. You can start your tape write
with 500 filemarks, then a single block of data. You'll always be able to
get that single block back.

The story of not being able to read past two filemarks is based on the fact
that it normally marks the end of a write session. In many data streams, the
end of *logical* data is marked by writing two consecutive filemarks. It
serves as an append point for later sessions. Tape, being sequential media,
also writes a *physical* end-of-data marker at that point, and usually it's
followed by an erase gap. Depending on the implementation, the erase gap is
a single track, or can be a number of tracks wide. It invalidates any tracks
behind the end of data marker, by partially or completely erasing them.

Reading past such an area is normally prevented in firmware, as anything
behind the EOD marker is not considered part of the current tape sequence
(remember, sequential data). However, most drives can be persuaded to skip
such an erase area to the next valid filemark, and can continue to read from
there on. Data recovery centers use this feature to get 'overwritten' data
back. I've written software to even automate the recovery process on
EXB-8200 through 8505XL, it's very easy to do. On most helical scan drives
you can do this. On most linear drives you can do this too (except DLT7000,
as it destroys multiple tracks with a single write).

Rob