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@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
