testing initiator mode with DDS tape drive #131
Comments
|
Thanks for testing and the detailed notes - Looking at the specs - sequential access drives do behave differently than direct access - eg you cant seek as you note. The commands cdb's will differ a bit as you can see here between seq on the left, direct on the right: It seems we'll need to detect sequential drives and adjust the flow/commands. I unfortunately do not have a sequential drive(though may be able to borrow one). In the meantime I can help you dig into this too if you'd like (spec/code/etc) - just let me know! |
|
Hi @erichelgeson, I'm hoping to focus on workflows related to these tape drives so very willing to dig in or collaborate. In chatting with @pdicamillo, he suggested that I power on the drive, use the DATXtract software which could switch the drive in between audio mode and data mode (since I've been testing with DAT audio tapes can tools like DATXtract or readdat can transfer via these tape drives) and then swap the drive back to BlueSCSI while it is in audio mode. So I'm moving to run this test today. |
|
I tried a new test where I connected the SONY SDT-9000 tape drive to a Mac G3 via a SCSI 50 to 25 cable to a PCIe card in the computer. I then ran DATXtract and confirmed that the tape drive could respond to that application and transfer data. After DATXtract had switched the tape drive into AUDIO_MODE I then swapped the internal 50 pin ribbon of the tape drive enclosure to the BlueSCSI. Here's the debug log from that: https://gist.github.com/dericed/0b24a3ccf69bb18deef57d1f41ea26ee. I can try any other suggested tests or may look into how to compile BlueSCSI so I can try adjusting the read commands as @erichelgeson suggested. |
|
I've got a bunch of SCSI tape drives (mix of HP and Archive/Conner/Seagate/Certance/Quantum) and a SCSI Bus Analyser so could potentially look into this, even if only for testing and advising. One issue you're going to see with sequential devices is that they stream data - and they have the concept of "filemarks" which you can seek forward and backward through. At the end of the tape is an EOT marker (usually two EOFs) which the device will signal as an "end of tape". This may not be the end of the physical tape, but it is the end of the readable data. A write operation will effectively overwrite all the subsequent files, then write a new EOT, making any remnants of that data inaccessible. For added annoyance, many tape drives support variable block sizes: this could be anything from 256 bytes up to a megabyte or more, depending on how the backup software used the tape. For DAT/DDS, you're likely to see blocks of 32K. Tapeimgr has an implementation of block-size probing and could be a good starting point for Initiator support for Sequential (tape) devices: https://github.com/KBNLresearch/tapeimgr Some kind of image format or storage scheme will need to be cooked up to store the output files, and keep track of block sizes. The 99% use case is, the block size is consistent throughout the file, and only needs to be probed at the start of the file. To make this hairier, DDS tapes can be partitioned in two (at least on data tapes), but this wasn't commonly done. Generally this would be for something like HP's OBDR (One Button Disaster Recovery) where the first partition would contain a bootable ISO image which could restore a backup from the second (backup data) partition. I think LTO has this, but it's only been added comparatively recently (having checked - 2010, with LTO-5, and LTO-6 expanded it from two partitions to four). Seagate has a pretty decent SCSI manual on their DDS tape streaming devices: http://www.bitsavers.org/pdf/seagate/tape/10002663-003_Seagate_DAT_Tape_Drives_and_Autoloaders_SCSI_Manual_199702.pdf For supporting DAT (audio), there's DATLib, http://www.hoxnet.com/dat-tools/datlib |
|
Hi @philpem, I consider parsing the data stream to be the easier part of this challenge. The DAT audio frame is pretty simpler with a fixed number of bytes of PCM audio then with a footer that contains the metadata, parity info, markers, etc. So a segment of a DAT tape data stream whether the whole tape or a segment could be parsed. I'm curious if I'm wrong but I presumed that parsing or interpreting the resulting image was out of scope of the initiator feature. |
|
I'm not suggesting there be any parsing or interpreting going on - I figured you were trying to read a DDS Data tape in a DDS drive (not a DAT Audio one). So my points (that there'd need to be ways of storing the block size and file marks) only apply to DDS. For DAT - it's been a while since I used my DDS drive (I use an Archive Peregrine DDS-2) but from what I remember you're correct. I'd again consider the DATLib source code the authority on how to do this. You'd have to essentially reimplement it on the BlueSCSI-V2. The extra data, incidentally, is called the "sub code" or "sub data" and is specified in IEC 61119-1 (sub data and DAT data track) and IEC TR 61119-4 (text-format TOC and track-name data). DATLib implements enough of this to get by. |
In the initiator mode documentation I saw this line
Support for Tape Drives and other Targets is currently unknown, and would require test devicesso I wanted to share notes from my test with that.I loaded a SONY DDS3 SDT-9000 drive with a tape, set the pins the tape drive to use SCSI ID 3. My ini file is simply set to
I connected a 50 pin ribbon cable from a BlueSCSI Desktop V2 (with wifi) to the SDT-9000.
I powered up the BlueSCSI and then powered up the SDT-9000. It took about 20 seconds for the SDT-9000 to cue the tape before the busy light turned off. From there the green led on the BlueSCSI would steadily blink and the Status light on the SDT-9000 would blink but beyond the initial cueing routine of the deck, the tape did not move as if being read. After a few minutes, I turned off the drive and then the BlueSCSI.
On the BlueSCSI's card was a
HD30_imaged.hdafile of a gigabyte but it was zero filled. Here is the log.txtFrom this log I can see some success.
In this section:
I cross-referenced the third byte
0x05to the DATXtract source code and this value means Illegal Request.From here I added
Debug=1and repeated the test (first powering up the BlueSCSI and then the tape drive). Similar result, there is a 1 GB zero-filled file calledHD31_imaged.hdaand the verbose log is pasted here: https://gist.github.com/dericed/50345d9299d61159649300a5f782b21a. That's as far as I got today and wanted to share notes to see if you have advice on what to try of this tape drive next.Thanks for your work on this project.
The text was updated successfully, but these errors were encountered: