IO error when attempting to export a tape

52 views
Skip to first unread message

Tim A

unread,
Nov 20, 2020, 4:08:28 PM11/20/20
to QUADStor VTL
Hi all,

Another question. I'm working with QStar connected via iSCSI to QuadStor.

For the most part things are working well now. However, after I issue the first "tape export" via QStar any subsequent exports of the tape seem to return some sort of "IO Error"

This is what is reported on the QStar side from what I can get from the SCSI log:

  "11/20/2020 13:37:05.2592 0.0075 QSTOR:jbctl  move medium           a5 00 00 00 10 05 00 11 00 00 00 00 ILLEGAL REQUEST: MEDIUM REMOVAL PREVENTED=(05 53 02 )  tm=600 carrier 0 from slot 6 to mailslot 2"

I've bumped up the logs as much as I can on the QuadStor side but I don't see a lot of extra logging going on I don't think. Maybe a bit more but not as much as I would think. And certainly nothing when I get this IO error.

Now, if I restart the QuadStor service and try the exact same export it works fine. And then attempting to export another tape on another slot. IO error. Rinse and repeat.

Again I can't tell if its a QuadStor issue or QStar. Seems to me that something is getting out of sync or something hanging up on the QuadStor side of things.

Also of note. When I tail -f the quadstor.log file I notice that the output is usually lagged for a long period of time. However, if I go to the web interface System -> VTL Log -> View I see that it immediately dumps to the log. Probably doesn't mean a lot but makes it difficult to just sit there and watch the log with "tail -f".

Any help or pointers on what I could look at further would be greatly appreciated.

QUADStor VTL Support

unread,
Nov 20, 2020, 4:22:21 PM11/20/20
to quadstor-vtl
Hi,

On the VTL side, you could add CmdDebug=1 to /quadstorvtl/etc/quadstor.conf (the file needs to be created if it does not exist), then run the command
/quadstorvtl/bin/vtconfig --reload

After that please retry the exports till the same error is encountered. Then send the diagnostics logs to vtlsu...@quadstor.com

Regarding tail -f quadstor.log, the log file isn't flushed to disk every time there is a write, when viewing the log in the GUI the log file is flushed to disk. 

Please note that CmdDebug=1 will generate quite a few messages, especially when there are reads or writes to tape. It should be disabled after generating the diagnostic logs by either removing the line or setting CmdDebug=0 and followed up by
/quadstorvtl/bin/vtconfig --reload

The problem here seems to be that a SCSI PREVENT ALLOW MEDIUM REMOVAL is set either on the drive the tape was loaded or on the medium changer. If on the drive the unload from the drive is prevented and if set on the medium changer moving the tape to an import/export port is prevented. Whether this is an issue at the VTL side or by the application can be determined from the logs with CmdDebug=1 set.


--
You received this message because you are subscribed to the Google Groups "QUADStor VTL" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quadstor-vtl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quadstor-vtl/610fcc20-c47b-44bf-81bd-67331df18c2dn%40googlegroups.com.

Tim A

unread,
Nov 21, 2020, 10:57:40 AM11/21/20
to QUADStor VTL
Thanks for the reply.

I already tried CmdDebug=1 or maybe it was =2 with both doing the vtconfig --reload and also restarting the entire service because it looked like there wasn't much being dumped in the logs. I will try again in case I have something incorrect in quadstor.conf but I would suspect if I did I'd get something indicating that in the logs.

I probably won't get back to this until early next week and will report back if I'm able to get any additional logs or not.
Reply all
Reply to author
Forward
0 new messages