From: Mike Christie <michaelc@cs.wisc.edu>
To: Kay Sievers <kay@vrfy.org>
Cc: Hannes Reinecke <hare@suse.de>, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 0/4] notify userspace of offline->running transitions (v2)
Date: Mon, 21 May 2012 12:04:21 -0500 [thread overview]
Message-ID: <4FBA7595.8020400@cs.wisc.edu> (raw)
In-Reply-To: <CAPXgP10t_pMCJuavrBsNcyv1XKy4WThV8CfVBz-4wD=Q_fq_=w@mail.gmail.com>
On 05/21/2012 11:49 AM, Kay Sievers wrote:
> On Mon, May 21, 2012 at 5:35 PM, Mike Christie <michaelc@cs.wisc.edu> wrote:
>> On 05/21/2012 06:50 AM, Hannes Reinecke wrote:
>>> On 05/18/2012 06:56 AM, michaelc@cs.wisc.edu wrote:
>>>> The following patches were made over the misc branch of the scsi tree.
>>>>
>>>> The patches fix a issue where if the device is offlined or IO is
>>>> failed due to fast_io_fail (fc) /recovery_tmo (iscsi) then comes
>>>> back, apps do not have a way a nice way to figure out the state
>>>> has transitioned to running. Apps have to either poll the sysfs state
>>>> file or send a SG IO to figure it out. With the patch apps can listen
>>>> for the KOBJ CHANGE event like some of them (at least udev does) do
>>>> already.
>>>>
>>>> v2:
>>>> - Rebased to misc.
>>>>
>>> In principle, yes.
>>>
>>
>> ccing Kay.
>>
>>> However, when doing this, we're now sending 'CHANGE' uevents from
>>> SCSI devices. With the potential of putting _quite_ some strain on udev.
>>> Kay explicitely debarred me from using uevents for my SCSI sense
>>
>> Kay told me to do it this way :) In this case udev was the app we
>> discovered the issue with, so maybe that is the diff.
>
> Hah, I basically only told you not to use online/offline events. :)
Yeah, I guess you guys got me confused :) Harold said to send an event
for this issue. Then later you said "please always use change". I
thought you and Harold were in sync :(
>
> Uevents are ok to use if we can be sure there is _never_ a storm of
> events. Uevents are not meant to handle large amounts of events
> happening at the same time. They must never be used to handle things
> like reporting errors which are not limited in their rate, or where
> many devices might send similar events at the same time in a row.
>
In this case you can get many devices sending the same events at the
same time, because when the transport/connection comes back you all the
device accessed through that connection will be set to running at the
same time.
So what is the fix for this case? Just send one event for the host or
transport/connection then have udev loop over all devices accessed
through that object and fix things up? If so, what type of event do you
want? CHANGE event plus some other info to indicate to look at child
devices?
next prev parent reply other threads:[~2012-05-21 17:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-18 4:56 [PATCH 0/4] notify userspace of offline->running transitions (v2) michaelc
2012-05-18 4:56 ` [PATCH 1/4] SCSI: add new SDEV_TRANSPORT_OFFLINE state michaelc
2012-05-21 11:50 ` Hannes Reinecke
2012-05-18 4:56 ` [PATCH 2/4] SCSI, classes, mpt2sas: have scsi_internal_device_unblock take new state (v2) michaelc
2012-05-18 4:56 ` [PATCH 3/4] SCSI: remove old comment from block/unblock functions (v2) michaelc
2012-05-18 4:56 ` [PATCH 4/4] SCSI: send KOBJ_CHANGE when device is set to running v2 michaelc
2012-05-21 11:45 ` Hannes Reinecke
2012-05-21 15:32 ` Mike Christie
2012-05-21 15:46 ` Mike Christie
2012-05-21 11:50 ` [PATCH 0/4] notify userspace of offline->running transitions (v2) Hannes Reinecke
2012-05-21 15:35 ` Mike Christie
2012-05-21 16:49 ` Kay Sievers
2012-05-21 17:04 ` Mike Christie [this message]
2012-05-21 19:15 ` Kay Sievers
2012-05-22 13:33 ` Hannes Reinecke
2012-06-06 21:18 ` Mike Christie
2012-06-26 21:48 ` Mike Snitzer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FBA7595.8020400@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=hare@suse.de \
--cc=kay@vrfy.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).