This issue with this post is EOD.
The links you posted show standard 'SCSI' commands to a tape drive.
A modified Windows/Unix driver will not allow for reading in not conventional ways. There are not many commands with a tape drive. Basic ones are Read (fixed or variable block size), Space (locate) Rewind.
Any guidance where I can find the 'Raw read' command, as opposed to just reading tape blocks.
I know, this is EXACTLY why I specified "(set aside the EOD issue)"
From the Tolis manual I linked to.
Reading a tape with taperead
The taperead utility reads the raw data from a tape and provides it as
standard output to be used by whatever utility that you wish to pipe it to.Â
you can sue the good Tolis guys if you believe they misrepresented what that tool does.
Â
A driver (at least under Windows) can do "queer" things, though, as said I believe that *something* else is used by the specialized tape recovery companies, a common example (again unrelated to this thread and provided ONLY as a comparison) is the special driver coming together with some "Manufacturer Tool" for USB sticks, that provide access to areas of the stick or of its controller that are otherwise unreachable.
jaclaz
Â
Reading a tape with taperead
The taperead utility reads the raw data from a tape and provides it as
standard output to be used by whatever utility that you wish to pipe it to.ÂÂ
I am fairly certain that in this context, 'raw data' is just block by block data off the tape. This is a simple SCSI command.
It does nothing to help with the question of reading past EOD.
Â
I have no intention of suing anyone. I just want to try and help with the original question in a field I have worked on for over 35 years, which has involved many 100s of hours pouring over SCSI reference manuals for all types of tape drive, starting with Open Reel Tape (9 track), and with SCSI, SAS, Fibre, USB, Pertec interfaces for DOS, Windows and Unix.
It does nothing to help with the question of reading past EOD.
And AGAIN I know, and explicitly said so, TWICE.
The EOD can be bypassed AFAIK ONLY by a tape drive with modified firmware, or - but I strongly doubt it can apply to LTO/LTFS tapes -  maybe with this or similar approach:
http://pages.cs.wisc.edu/~plonka/sysadmin/backup.html
which is clearly a high risk one and which I explicitly DO NOT recommend.
jaclaz
So basically you/we do not have a solution for the original question.
Â
I hope his recovery company can assist
So basically you/we do not have a solution for the original question.
Â
I hope his recovery company can assist
Sure we have it not for the original question, if you check I was replying to the later questions, the ones that go like:
my questions is :Â
i have contacted a recovery service company regarding this tape before and after i sent them some information about the software , they said that it is possible to get back the data. if there is no software can be used in my situation . how does all these recovery companies work ? what are the tools they used to their magic ? I'm not specialized but of course I have a a great curiosity .
which I had explicitly quoted.
Questions in this thread by the OP:
1) can anyone give my an advice on how i can manage solving this problem or even a software that can be used ?
2) if there is no software can be used in my situation . how does all these recovery companies work ?
3) what are the tools they used to their magic ?
You replied to #1, I tried to answer #2 and #3.
jaclaz
I sent an email to the Archiware P5 company to get more information regarding how the tape is written and if they have any suggestions. Here is what they say:
Â
"
I am afraid that is not possible:
During labeling, a new "label" is written to the beginning of the tape.
When writing to tape, the drive adds an EOD (end of data) after the written data.
The LTO consortium is now very strict in making sure that reading a tape after the EOD
mark is not possible. As a consequence, there is no drive firmware that is capable
to read after EOD.
There are some companies like OnTrack who may be capable to read such data, but that
must be very expensive as we had a few cases like this in the past and we never heard
about a case where this was done (as we assume we well need to assist when it comes to
extract the data from the the block format of P5).
There is a second reason why this is probably not possible:
While we regard a tape as a linear storage, it physically is not that linear. The drive
writes tracks while moving forward and backward on the tape. An LTO-5 tape for instance
has 1280 tracks, and while writing the first track, the drive's erase head will clear
all tracks in parallel. That means on an LTO-5 tape, you will have after labeling
1280 erased sections in the data, each section at least as long as the label area (a few 100 Kb).
Regarding your questions:
> 1-are the tapes partitioned while labeled .
> so that , there is partition for label/index and other for data (like LTFS) ?
No, the tapes are not formatted in standard (non LTFS) format.
> 2- how many bytes does the label takes and where the data starts if
> the tape is one partition?
The are a few hundred Kilobytes, as there is a tar file at the beginning of the label.
But you cannot position on a tape in bytes, but in file marks. These are marks written
by the drive. The data after the label is at filemarks 11. On a linux box you could get there
with
mt -f device fsf 11
however you will see that is where the EOD mark is.
> 3- what is the format of the data on the tape (tar or something else )?
P5 uses a proprietary block format, blocks have constant size (in version three one block was 32 KB),
the blocks contain file metadata and the files itself, possible followed by further blocks which may
contain further data of the same file.
In case you would get so far that you get the data blocks from the tape (what I don't expect),
it may make sense to contact us for extracting the files from these blocks.
"
Â
Does this ring any bills?Â
Â
Â
Thanks for the update. Â It actually confirms my first response.