On Wed, 6 Feb 2008 10:43:32 -0500, David Boyes <[EMAIL PROTECTED]> wrote:
> > > That seems kind of counter-intuitive. A device clearly just changed > > > state in an important way -- shouldn't that be something udev should > > > care about, or at least be notified of? Udev can always choose to > ignore > > > the events. > > Well, uevents are mainly created when devices are added/removed > to/from > > the system. Setting a device online/offline only changes some > > attributes for an existing device. > > True. I think it could be argued that that change (a device going > unavailable or coming back) might need some reaction from elsewhere in > the system, so it would be good to let udev know, and let udev decide if > it cares or not. Modern udev shouldn't be too much of a problem. However, programs with suboptimal implementation regarding the handling of many devices may slow down the system even worse if they see more events. (I once considered adding events on online/offline for the consumption of one of those programs, but it seemed everybody was fine without it...) > In the case of FCP disks, I know *I* care, and so I > could decide what to do based on what happened. Hm, maybe I should reconsider... change events may not be that bad. > > ...so a better solution may be to have zfcp generate a uevent here? > > (I'm not too happy with adding uevents whether they are needed or not. > > Too many uevents create a high system load from some tools.) > > I can think of two major cases where you'd get a burst of these: during > startup, and during a reconfiguration. In both cases, I think you'd > expect them because the I/O system is doing what it's supposed to do, > and hopefully it shouldn't happen too often. I guess I'd consider this > kind of configuration change to be an exception. > > If it does happen (or there are overzealous event consumers polling for > events) very often, I think the problem is likely to be a) more serious > and/or b) fixable elsewhere. Well, if your configuration change makes your system unusable, it is serious... (Most of the problem comes from the actions triggered by the events. Good luck trying to get the consumers fix their stuff :() > > I guess it comes down to how frequently one reconfigures devices. Unexpected failures (which would be easily recoverable) may trigger an event storm as well... ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
