> On 9.2.2015, at 8.00, Seymour, Shane M <shane.seym...@hp.com> wrote: > > Kai - see last 3 paragraphs for question about if something is a bug or not. > > BTW I had a look - I couldn't quickly find out if there was a way to tell if > the medium has changed in a tape drive (there could be something device > specific). At the device level there's a record of I/O errors: > > [root@tapedrive device]# pwd > /sys/class/scsi_tape/st0/device > [root@tapedrive device]# cat ioerr_cnt > 0x5 > > That doesn't distinguish between read or write or any other kind of error > though - it doesn't even really have to mean an error since reading with a > block size too small also increments the error count:
The counts in the device directory are not specific to tapes. From linux/scsi/scsi_lib.c one can see that ierr_cnt is incremented every time the scsi call returns any kind of error, including when the tape drive wants to return some information with sense data. > [root@tapedrive tape-stats]# ./tape_exercise write /dev/st0 /dev/urandom > 1000000 > About to write from /dev/urandom to /dev/st0, max size = 1000000, blksize = > 4096 > Write complete on /dev/st0 after 1003520 bytes > ./tape_[root@tapedrive tape-stats]# ./tape_exercise read /dev/st0 > About to read from /dev/st0 blksize = 256 > Failed to read from /dev/st0 using current blksize, will try using a bigger > blksize > About to read from /dev/st0 blksize = 512 > Failed to read from /dev/st0 using current blksize, will try using a bigger > blksize > About to read from /dev/st0 blksize = 1024 > Failed to read from /dev/st0 using current blksize, will try using a bigger > blksize > About to read from /dev/st0 blksize = 2048 > Failed to read from /dev/st0 using current blksize, will try using a bigger > blksize > About to read from /dev/st0 blksize = 4096 > Reading complete for /dev/st0, 987136 bytes read > > [root@tapedrive tape-stats]# cd /sys/class/scsi_tape/st0/device > [root@tapedrive device]# cat ioerr_cnt > 0xa > > It would seem that ioerr_cnt is probably a count of SCSI check conditions > encountered? > > Unfortunately for the MTIOCGET ioctl the value of mt_resid is the partition > number of the tape not what I would have expected it to be - the residual > left after the last read or write that returned an error (and 0 if the last > read/write didn't return an error). > > Kai - is that a bug? Shouldn't mt_resid be the residual from the last failed > read or write indicating how much data didn't make it to the device and 0 on > a successful read or write? I've used mt_resid from MTIOCGET on HP-UX > previously when issuing reads and repositioning and retrying tape reads when > starting with too low a block size to try and automatically determine the > block size in use (it's never a good idea to under or overread tape blocks > because it always results in check conditions and in the st driver under > reading the block size always creates messages in dmesg). > This is not a bug. man st documents that mt_resid does return the partition number. In the different unix systems the field did not consistently return the residual count. The Linux SCSI drivers did not at that time return the residual. These are reasons why the field is used for partition number. For writes in any real situation (drive in buffered mode) you don’t know when the write() returns whether the data can be written to tape. All writes are on tape when write file marks returns successfully of the device is successfully closed. I am not sure that the amount of data successfully written is really useful. If I see a write error, I want to rewrite at least the latest file. For reads, there are other ways to determine the block size. (Use a large enough byte count and see what you get.) The st driver does not write to the log if the block is shorter than requested. Short read is logged (together with the real block size). If you don’t want the overhead of returning the sense data for short reads, you can set the SILI flag. > If you don't have time to look at it I may look at if it's possible to > provide the correct mt_resid for MTIOCGET - assuming that a long time if > misuse prevents us from correcting it. If there's no way to export a > partition number for the devices that support it I can add a new sysfs file > (call it partition) to export it that way and see if I can get the correct > value into mt_resid. > Changing the definition of a field should not be done. There is software that is correctly using the field as it is documented. Kai -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
