Re: notify userspace of offline - running transitions

2013-09-25 Thread Hannes Reinecke
On 09/24/2013 09:23 PM, Ewan Milne wrote:
 http://marc.info/?l=linux-scsim=133901769900806w=2
 
 Can we reconsider applying patch 4 in Mike's set?
 The problem still exists, and there was never another
 solution proposed as far as I can see.  (I posted a
 question about this a while back...)
 
 It is a big issue for people who happen to get a
 KOBJ_CHANGE uevent while their iSCSI session happens
 to be disconnected for some reason, because udev
 will end up removing the /dev/by-xxx links when it
 can't access the device.  If there is no subsequent
 uevent when the device is available again, the links
 are never recreated.
 
Right. The original issue here is that we'll be getting a 'CHANGE'
uevent for _EVERY_ device connected to that port / iscsi session.

This has two potential issues:
1) We'll be pushing quite some events through udev, increasing the
load at times when already is quite some I/O going on.
2) Currently SCSI devices only had to react to 'add' events for
generating udev links, with 'change' events virtually non-existing.
When we're not generating 'change' events for SCSI devices we
absolutely have to audit / test the udev rules as they need to
re-create _all_ device links etc on 'change', too.
Otherwise we'll end up with the situation you've just described.

Hence my original comment to send 'change' events for the session or
rport, as this would result in only _one_ event thereby eliminating
the event multiplication.
It has the drawback that we won't get the automatic udev database
update like we would be getting with the patch.

But then we could easily achieve that by auditing the udev rules to
fetch the required information off the udev database in case the
device is not accessible.
And as we have to audit the udev rules _anyway_ it feels like a
better solution to me.
(It certainly is for me, as I've already done this on the SUSE side;
we've had a similar issue already :-)
But if others feel strongly about this patch I won't object to it.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: notify userspace of offline - running transitions

2013-09-24 Thread Ewan Milne
http://marc.info/?l=linux-scsim=133901769900806w=2

Can we reconsider applying patch 4 in Mike's set?
The problem still exists, and there was never another
solution proposed as far as I can see.  (I posted a
question about this a while back...)

It is a big issue for people who happen to get a
KOBJ_CHANGE uevent while their iSCSI session happens
to be disconnected for some reason, because udev
will end up removing the /dev/by-xxx links when it
can't access the device.  If there is no subsequent
uevent when the device is available again, the links
are never recreated.

-Ewan


--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: notify userspace of offline - running transitions

2013-05-06 Thread Ewan Milne
http://marc.info/?l=linux-scsim=133769378525796w=2

Did anything ever happen with this?  I don't see that it did.

There seems to be a problem with udev processing an event
for a device at a time when the device can't be accessed.
Mike's original fix was to generate another KOBJ_CHANGE
event when the device comes back online, so that subsequent
udev rule processing would succeed.  Even so, the device
could become inaccessible again by the time the event was
actually processed by udev (if udevd was overloaded...)

-Ewan




--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html