On Tue, 2016-02-23 at 18:27 +0800, Hannes Reinecke wrote:
> On 02/22/2016 11:34 PM, Bart Van Assche wrote:
> > On 02/21/16 22:59, Hannes Reinecke wrote:
> >> The main reason why I need the 'access_state' attribute is to decouple
> >> the multipath daemon; at the moment the multipath daemon has to
On 02/22/2016 11:34 PM, Bart Van Assche wrote:
> On 02/21/16 22:59, Hannes Reinecke wrote:
>> The main reason why I need the 'access_state' attribute is to decouple
>> the multipath daemon; at the moment the multipath daemon has to issue
>> REPORT TARGET PORT GROUPS frequently to figure out the
On 02/21/16 22:59, Hannes Reinecke wrote:
The main reason why I need the 'access_state' attribute is to decouple
the multipath daemon; at the moment the multipath daemon has to issue
REPORT TARGET PORT GROUPS frequently to figure out the status, which is
causing quite some load on the target.
On 02/22/2016 05:45 AM, Bart Van Assche wrote:
> 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'
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
> "Hannes" == Hannes Reinecke writes:
Hannes> Martin, can you please ignore patches 20-22 when pulling the
Hannes> patchset? I'll be resubmitting a new patchset with them once
Hannes> these issues are sorted out. Or do you need a new patch
Hannes> submission?
No, it's OK.
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
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
On 02/19/2016 08:10 PM, Bart Van Assche wrote:
On 02/19/2016 12:17 AM, Hannes Reinecke wrote:
+static ssize_t
+sdev_show_access_state(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct scsi_device *sdev =
On 02/19/2016 12:17 AM, Hannes Reinecke wrote:
> +static ssize_t
> +sdev_show_access_state(struct device *dev,
> +struct device_attribute *attr,
> +char *buf)
> +{
> + struct scsi_device *sdev = to_scsi_device(dev);
> + unsigned char access_state;
>
Add an 'access_state' attribute to struct scsi_device to
display the asymmetric LUN access state.
Reviewed-by: Ewan Milne
Reviewed-by: Christoph Hellwig
Signed-off-by: Hannes Reinecke
---
drivers/scsi/scsi_sysfs.c | 53
11 matches
Mail list logo