Hi Martin, 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: 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 <mwi...@suse.com> 收件人: tang.jun...@zte.com.cn, 抄送: dm-devel@redhat.com 日期: 2016/11/17 18:57 主题: Re: [dm-devel] Improve processing efficiency for addition and deletion of multipath devices 发件人: dm-devel-boun...@redhat.com 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@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
-- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel