On 02/21/16 00:27, Hannes Reinecke wrote:
On 02/20/2016 04:16 PM, Bart Van Assche wrote:
On 02/20/16 00:03, Hannes Reinecke wrote:
Also when using your suggestion the 'access_state' attribute will only
be created _after_ the 'ADD' uevent, making it impossible to use it from
udev events.
Can you give an example in which it would be useful to read the ALUA
state from a udev handler ? I'm not sure such an example exists.
When evaluating the 'access_state' from an uevent we can avoid sending
I/O if the path is unavailable; eg if the path is in 'transitioning' I/O
will be queued until that path becomes available again.
Which means that the uevent will be delayed during udev processing, so
that the event will never be read by multipathing (as it's being invoked
only after udev event processing has finished).
And in extreme cases (like OnTap takeover/giveback) it will even drop
the event completely due to a timeout.
Hello Hannes,
Thanks for the feedback.
Please split the access_state attribute in two sysfs attributes - one
for the ALUA state and one for the "preferred" state. This will make it
easier for shell scripts to process these sysfs attributes.
I agree with using the 'is_visible' callback. But since using that
callback will cause the ALUA sysfs attributes to become only visible
after the ALUA handler has been attached I don't see why not to move the
implementation of the ALUA sysfs attributes into the ALUA device handler
source file.
BTW, since the ALUA state can change at any time after the access_state
sysfs attribute has been read and before I/O is submitted my preference
is to avoid triggering any SCSI commands from a udev rule that depend on
the ALUA state.
Bart.
--
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
