On Mon, May 21, 2012 at 7:04 PM, Mike Christie <michaelc@xxxxxxxxxxx> wrote: > On 05/21/2012 11:49 AM, Kay Sievers wrote: >>> 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 :( Yeah, Harald and I think that sometimes ourselves, but we are not always. :) >> 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. The problem would be more the possible highest frequency of the change. One event per device in a longer time frame would be ok, it's like coldplug at boot time, where we enumerate all devices once in one step. That is known though, to take minutes on very large boxes with thousands of devices. If we get such state change for lots of devices in a row (the state flips forth and back for all devices), faster than we handle them (and they are not that fast on older versions of udev, or if people plugged silly things into udev rules), things will break or get lost one way or the other. > 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? We do not really support such logic in udev. And it would cause exactly the same problem, just at a different layer. Kay -- 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
