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