FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 02-07-2008, 09:08 AM
Stefan Richter
 
Default scsi_dh: Add support for SDEV_PASSIVE)

Mike Anderson wrote:
> A number of user apps like lvm scanning that execute media access commands
> already have filter capability to filter devices that one does not want to
> scan. Another class of device scanners just use inquiries which are not
> effected by the passive state (though some could probably use udevinfo and
> reduce the amount of repeated SCSI inquiries execute on the system.

To expand on this:

At least on desktop systems and SOHO server systems, userspace should
_never_ issue INQUIRY. There are too many broken firmwares out there
which assume that there will never be more than one INQUIRY sent. They
start to return garbled data or crash if they get a second INQUIRY.
--
Stefan Richter
-=====-==--- --=- --===
http://arcgraph.de/sr/

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 02-07-2008, 02:01 PM
James Bottomley
 
Default scsi_dh: Add support for SDEV_PASSIVE)

On Thu, 2008-02-07 at 11:08 +0100, Stefan Richter wrote:
> Mike Anderson wrote:
> > A number of user apps like lvm scanning that execute media access commands
> > already have filter capability to filter devices that one does not want to
> > scan. Another class of device scanners just use inquiries which are not
> > effected by the passive state (though some could probably use udevinfo and
> > reduce the amount of repeated SCSI inquiries execute on the system.
>
> To expand on this:
>
> At least on desktop systems and SOHO server systems, userspace should
> _never_ issue INQUIRY. There are too many broken firmwares out there
> which assume that there will never be more than one INQUIRY sent. They
> start to return garbled data or crash if they get a second INQUIRY.

It's all very well to say this, but I think if you look at what udev
does, you'll find that it uses scsi_id to send a VPD inquiry to the
device so it can populate /dev/disk/by-id, so the point is already
conceded (and I think looking at a recent camera crash that seems to
have been precipitated by this, it's already causing us problems).

This is all a tradeoff. If you want userspace *never* to issue raw SCSI
commands like INQUIRY, we're going to have to provide the needed
information from the kernel via sysfs ... including VPD strings. This
is something we've always shovelled off into userspace before.

James


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 02-07-2008, 07:42 PM
Luben Tuikov
 
Default scsi_dh: Add support for SDEV_PASSIVE)

--- On Thu, 2/7/08, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> This is all a tradeoff. If you want userspace *never* to
> issue raw SCSI
> commands like INQUIRY, we're going to have to provide
> the needed
> information from the kernel via sysfs ... including VPD
> strings. This
> is something we've always shovelled off into userspace
> before.

What if a user-space application client _does_ send an INQUIRY to
a device anyway?

It would probably be better to preserve application client behaviour
and simulate/emulate n-th INQUIRY, after the 1st for such broken
device firmwares that break on any subsequent INQUIRY. Possibly
in the LLDD or via blacklisting in the mid-layer.

Luben

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 09:47 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org