I am writing data to a tape using a real-time OS. Not
Solaris. I am attempting to read it back in Solaris.
There's more than one issue involved and I am pursuing
the writing side closely as there must be some difference
THERE to cause this, but there is also this difference
between the Solaris implementation and the Windows, and
it is not well understood.
Details are bizarre so follow closely.
1. The application is writing scan data to a tape in
real-time at 4.2 MB/Sec. The tape is a
DLT. Each scan is about 338 KBytes in size.
2. Because the tape speeds up and slows down and
occasionally reverses direction the application
must queue scans and issues write commands for
the queue contents at irregular intervals.
3. There are 2 versions of this code, one built 2
years ago and another more recent. Both appear
to function identically, call them '02 and '03.
4. The resulting tapes are ( or appear to be so far )
identical when read under Windows. When read under
Solaris the Solaris driver appears to break down at
the scans where one fwrite ends and the next begins.
This affects dd and the custom scan reader, but NOT
the mt utility. mt -f /dev/xxx fsf 1 shows exactly
the files and EOF marks we expect to see. The scan
sizes are 5.5 x the Solaris 61440 transfer block
5. The scan breakdown appears to be related to the ibs
in the Solaris implementation, which defaults to the
61440 maximum. Data appear normal up to the failure.
6. This failure only occurs in the '03 code, not the '02
code. There are no errors in writing. Both versions
are readable under Windows, the '03 code has this
trouble in Solaris.
I am currently going through the drivers and some possible
alignment differences in the code, but thought it useful
to ask this board if there's anyone with any idea what is
going on here that can add to what I know so far. I
suspect that there is something funny happening at the end
of the last partial block written and the beginning of
the first block in the next write, but I haven't got ANY
way to understand that at present.
Peculiarities related to read and alignment are of
... and YES I know I should be using a disk. I have the
disk. I have not received Management support to fix this
problem though it has cost (wasted) almost 2 man-years to
it has given ).
It is used on AVIRIS