Re: [PATCH] st: Do not rewind for SG_IO

[Douglas Gilbert <dgilbert@interlog.com>]

On 14-02-06 10:13 AM, Hannes Reinecke wrote:
> On 02/06/2014 03:38 PM, James Bottomley wrote:
>> On Thu, 2014-02-06 at 08:50 -0500, Martin K. Petersen wrote:
>>>>>>>> "Hannes" == Hannes Reinecke <hare@suse.de> writes:
>>>
>>>>> My patch provides both the original VPD 0x83 and 0x80 bits as well as
>>>>> a handle identical to /sbin/scsi_id.
>>>>>
>>> Hannes> Bah, don't do that.  That should better be handled by udev
>>> Hannes> rules.  I've got a set of patches moving from scsi_id to sg_inq,
>>> Hannes> which can be easily adapted to using sysfs directly.
>>>
>>> I just want to get out of the "userland sending random SCSI commands"
>>> business. That is a world of pain right now.
>>
>> Well, in the words of Bill Clinton "I feel your pain".  However, I need
>> to know we won't pick up that same whole world of pain in the kernel.
>> Remember it's not just SCSI devices, it's also ATA devices and
>> potentially other block devices ... then there's blkid and all the weird
>> things it does. Then there's transport identifiers for multi-path
>> reservations and so on.
>>
> blkid is actually not so bad, _if_ it would distinguish between
> 'metadata not found' and 'I/O error during metadata read'.
> I made a patch which hopefully should find it's way upstream.
>
> And blkid just issues plain READ commands, so _this_ behaviour won't
> change ...
>
>> Convince me this path won't have us shifting a whole bunch of weird from
>> user space to the kernel without any reduction in the weird factor.
>> Remember the point is not what can we do for all the nicely behaved
>> SCSI-3 devices, it's what do we do for everything.
>>
> Well, first and foremost the patch should be limited to SCSI-3 (and
> later devices). So we'd be insulated from the most obvious crap.
>
> So that leaves only devices which claim to be SCSI-3 or something,
> but still keel over when asked for VPD pages.
> However, this type of devices will fail already, as 'sd.c' is
> already asking for all sorts of VPD pages.
> Which leaves only non-Disk devices, but those tend to have a better
> SCSI implementation as you can't make quick bucks with, say, as SCSI
> Enclosure device.
>
> But the prime motivator behind this patch is that we can be
> reasonably sure the device will answer at all.
> When retrieving the EVPD pages from userspace you always have the
> problem that the device might have gone away or being unresponsive
> by the time you get around sending the SG_IO call.
> So you always have these stuck user-space processes asking for
> information which _had_ been present at one point. In particular
> udev is prone for this; anyone who ever came across the message
>
> udevd[]: worker unexpectedly returned with status 0x0100
>
> knows what I'm talking about ...

Running a small array with an external power supply which
is insufficient for the task of spinning up more than 1 or
2 disks is interesting to watch :-)

Doug Gilbert

> And the more udev events for a device you get, the higher the
> likelyhood for this to happen is.
>
> Plus I could re-use this information for my scsi_dh_alua patchset,
> and for xcopy and friends we'll be needing it, too.
>
> Cheers,
>
> Hannes
>