Dear all: seems like linux-tape@xxxxxxxxxxxxxxx is a very low traffic group. Last posting in archive is dated 2015. Please let me know if nobody is reading this :-) We built a new backup-software for our company (two HP 96slot libraries with 6 LTO5-drives). The software is written in PHP and we use a PHP-extension that let us talk to the library and to the drives. Communication with the libraries is done via the sg-device and uses the same SCSI-commands that the mtx-software uses. Communication with the drives is done either by reading/writing from/to the nstX-device or by doing MTIO-ioctl-calls. Works very well besides partitioning LTO-5 tapes which we dont do by MTIO-ioctl but direkt SCSI-commands on the sg-device of the drive. Now here's the problem: We would like to monitor our drives. When one process is writing a very large file another process should be able to detect what the current writing speed is and how much of the file has already been written. Since only one process can open a nstX-Device we are doing the monitoring by opening the sg-device and sending a Log-Sense command that requests the Data Transfer Device Status Log page. This delivers information about what the drive is doing (reading / writing / rewinding etc.). And with a Read Position command we fetch the current position- If you do this once per second you can easily calculate the current throuput (120-140 MB/sec) from the increasing block-values. This worked well for a long time until recently when we discovered that the file count from a MTIOCGET-ioctl gets out of sync from the file count from a Read Position call. Also very rarely WEOF-calls get lost and two backup files end up on tape as a concatenated single file. We were able to build a test-case: If our monitoring is disabled everything works as expected, if it runs in parallel the tape-driver gets confused. So the concurrent SCSI-commands are causing the confusion. Anybody out there with an idea why a "Read Position" or "Log Sense" command confuses the linux tape driver? My guess is that we should not send such commands to our drives when they are writing filemarks. Sending such commands while the drive is reading or writing seems to be no problem. If filemarks are not written (for whatever reason) then the ioctl-call should fail. It does not in our case and this seems to be a problem of the tape driver. Maybe the driver should lock the device to protect it against concurrent SCSI-commands while doing certain commands. Kind regards Peter -- To unsubscribe from this list: send the line "unsubscribe linux-tape" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
