On Sat, Jun 16, 2018 at 02:43:31PM +0200, linux-tape.pkoch@xxxxxxxx wrote: > 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 :-) yes, I'm reading it! But I have no help for you, never having done anything with enterprise-class tape drives, and not knowing anything about the various low-level things one might do with them. A couple of decades ago, when I joined this list, I was using a crappy floppy/tape drive, and that so far is the limit of my experience. That drive is long-since dead and gone, but I remain on the list just for learning purposes. It might be helpful to someone else (if there is someone else still reading this list) to mention things like which kernel version, distribution, controller brand/model etc., you're using, as well as things like: when did it stop working? what changed at or just before that time? Kernel update? driver update? PHP update? updated drive firmware? Replacement drive? full moon? ;) my wild guess is that the (SCSI??) driver (or the drive itself) is not dealing well with concurrent/overlapping commands from two different processes. threading problem?? If there is a list for Linux SCSI, or just plain SCSI, it might be worth posting there too, probably more traffic than this list. Good luck! Fred > > 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 -- ---- Fred Smith -- fredex@xxxxxxxxxxxxxxxxxxxxxx ----------------------------- God made him who had no sin to be sin for us, so that in him we might become the righteousness of God." --------------------------- Corinthians 5:21 --------------------------------- -- 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
