Hi Martin,
For your opinion:
For your opinion:
> My "filtering"
idea was meant for cases where several events
> for the same device are queued, e.g
> 1) add sda
> 2) change sda
> 3) delete sda
>Is it always sufficient to look only at the last event in such a case?
I do not agree with you. The reasons are as follows:
> for the same device are queued, e.g
> 1) add sda
> 2) change sda
> 3) delete sda
>Is it always sufficient to look only at the last event in such a case?
I do not agree with you. The reasons are as follows:
1) It’s risky to filter uevents
like that, a SCSI device has been generated,
May be its life time is very short, but we cannot turn a blind eye on it,
the system or applications may need multipath device of the SCSI device.
2) This scenario you mentioned rarely happens, we are more concerned
about the more common situation like addition or deletion devices when
iSCSI login/logout or FC link up/down with many iSCSI or FC links in
each LUN. At this situation we may receive many uevents from different
paths of the same LUN device, we want merge these uevents to one and
process them together.
Regards,
Tang
发件人: Martin Wilck <mwilck@xxxxxxxx>
收件人: tang.junhui@xxxxxxxxxx,
抄送: dm-devel@xxxxxxxxxx
日期: 2016/11/17 18:57
主题: Re: [dm-devel] Improve processing efficiency for addition and deletion of multipath devices
发件人: dm-devel-bounces@xxxxxxxxxx
Hi Tang,
> As to process several uevents for the same physical devices, I think
> the opinions
> different between us is "FILTER" or "MERGER". Personally, I think
> Merger is more
> accuracy, for example, we receive 4 paths addition uevent messages
> from the same
> physical devices:
> 1)uevent add sdb
> 2)uevent add sdc
> 3)uevent add sdd
> 4)uevent add sde
>
> We cannot just filter the 1)2)3) uevent messages but only process the
> 4)uevent message,
> which would cause losing paths of this multipath devices.
Of course. My "filtering" idea was meant for cases where several events
for the same device are queued, e.g.
1) add sda
2) change sda
3) delete sda
Is it always sufficient to look only at the last event in such a case?
I think so, but I'm not 100% certain.
Regards
Martin
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
May be its life time is very short, but we cannot turn a blind eye on it,
the system or applications may need multipath device of the SCSI device.
2) This scenario you mentioned rarely happens, we are more concerned
about the more common situation like addition or deletion devices when
iSCSI login/logout or FC link up/down with many iSCSI or FC links in
each LUN. At this situation we may receive many uevents from different
paths of the same LUN device, we want merge these uevents to one and
process them together.
Regards,
Tang
发件人: Martin Wilck <mwilck@xxxxxxxx>
收件人: tang.junhui@xxxxxxxxxx,
抄送: dm-devel@xxxxxxxxxx
日期: 2016/11/17 18:57
主题: Re: [dm-devel] Improve processing efficiency for addition and deletion of multipath devices
发件人: dm-devel-bounces@xxxxxxxxxx
Hi Tang,
> As to process several uevents for the same physical devices, I think
> the opinions
> different between us is "FILTER" or "MERGER". Personally, I think
> Merger is more
> accuracy, for example, we receive 4 paths addition uevent messages
> from the same
> physical devices:
> 1)uevent add sdb
> 2)uevent add sdc
> 3)uevent add sdd
> 4)uevent add sde
>
> We cannot just filter the 1)2)3) uevent messages but only process the
> 4)uevent message,
> which would cause losing paths of this multipath devices.
Of course. My "filtering" idea was meant for cases where several events
for the same device are queued, e.g.
1) add sda
2) change sda
3) delete sda
Is it always sufficient to look only at the last event in such a case?
I think so, but I'm not 100% certain.
Regards
Martin
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
