Re: st(4) and mt eom

[Frank Kardel <kardel%netbsd.org@localhost>]

On 03/21/19 07:00, John Nemeth wrote:

> On Mar 21,  6:48am, Frank Kardel wrote:
> }
> } As I wrote, extending MTIO ioctls to support more mt commands is not a
> } real issue (e. g. add access to the LOCATE command). We just need to
> } decide which features are useful to support and find the time to
> } implement them.
>
>       Yes, those would be enhancements, not bug fixes.  Also, what
> software would use these enhancements besides mt(1).  Some of the
> stuff, like informational items and control items, look to be useful
> in their own right, but other stuff, like locate, look to be
> redundant.
Yes, aggreed.
> } For Bacula it wouldn't help right now, thus the EOM code needs fixing.
>
>       For this, it is debatable if it is an enhancement or a bug
> fix.  However, it is needed by a significant application, which
> should raise its priority.
>
> } There are also some other things that are useful to add to the SCSI
> } subsystem like acquiring timeout information from the device to avoid
> } early device resets while the drive is still fighting with its servo
> } errors (just happened to me with a bad LTO7 drive). I have that update
> } currently sitting in my tree.
>
>       Getting timeout information from the device would be useful.
> I had a problem with an earlier tape changer.  If I issued a tape
> move command without first rewinding the tape, the operation would
> often timeout.  This would cause a SCSI bus reset to be issued
> while the tape was rewinding.  Then it would try to probe the
> changer while it was still resetting.  This drove the changer crazy.
> At first, I tried to remember to rewind the tape before issuing a
> move command.  Eventually I found the right spot in our code and
> changed the timeout.
I tripped over the same thing long time ago as some of our timeout 
constants are too low.
E. g. our LTO7 drive specifies 60 seconds for TUR, but the coded timeout 
for TUR is 15 seconds. Thus
getting the timeout values from the device is useful in case they are 
longer than our timeouts.
Unfortunately the changer device in our FlexStorII library does not 
provide timeout information.
Would be nice if it did. The drives provide the information for their 
operations.

But fetching the timeout is a plus anyway e. g. WRITE on our LTO7 drive 
can take up to 1560
seconds.

> } On 03/21/19 04:27, John Nemeth wrote:
> } > On Mar 20,  8:08pm, Frank Kardel wrote:
> } > }
> } > } This seems to be a long standing deficiency of the driver. Looking at
> } > } the SCSI spec it is recommended to issue a READ POSITION command
> } >
> } >       I did read a book about SCSI sometime ago, so I have a good
> } > overview of CCBs and the protocol, but it has been some time since
> } > I've looked at it in any depth.  And, although I've made minor
> } > changes to our SCSI code, I can't say that I know it in any depth.
> } >
> } > }
> } [snip]
> }-- End of excerpt from Frank Kardel
Frank