Hi Tony, On Wed, 22 Jun 2022, 7:56am, Tony Battersby wrote: > On 6/21/22 18:05, Arun Easi wrote: > > Thanks for the info. Just to reiterate, you've reported two issues (though > > this log was showing only 1 of them). > > > > Issue 1 - Tape device never disappears when removed > > Issue 2 - When a direct connected tape 1 was replaced with tape 2, tape 2 > > was not discovered. > > > > For Issue-2, please try the attached patch. This may not be the final fix, > > but wanted to check if that would fix the issue for you. > > > > For Issue-1, the behavior was intentional, though that behavior needs > > refinement. These tape drives support something called FC sequence level > > error recovery (added in FCP-2), which can make tape I/Os survive even > > across a short cable pull. This is not a simple retry of the I/O, rather a > > retry done at the FC sequence level that gives the IO a better chance of > > revival. In other words, the said patch that caused regression, while > > introduces an incorrect reporting of the state of the device, makes backup > > more resilient. > > > > Now, onto the behavior when device state is reported immediately. What we > > have observed, at least with one tape drive from a major vendor, is that, > > across a device loss and device back case with both the events reported to > > upper layers, the backup operation was getting failed. This is due to a > > REPORT LUNS command being issued during device reappearance reporting > > (fc_remote_port_add -> SCSI scan), which the tape drive was not expecting > > and caused the backup to fail. > > > > I know that some tape drives do not support multiple commands to it at the > > same time, but not sure if that is still the norm these days. > > > > So, perhaps one way to make the behavior better, is to either report the > > disappearing device a bit delayed or have intelligence added in SCSI scan > > to detect ongoing tape IO operations and delay/avoid the REPORT LUNs. > > Former is a more contained (in the LLD) fix. > > > > Regards, > > -Arun > > Your patch does fix Issue-2 for me. For Issue-1, it would be fine with > me if qla2xxx reported device removal to the upper level a bit delayed, > as you said. > Thanks for testing and verifying the patch. We will post the patch upstream after due testing. Regards, -Arun
