On mar, 2005-03-29 at 17:15 -0500, goggin, edward wrote: > The multipathd from 0.4.4-pre4 has died a 3 more times. > I am still not sure what's up here. > Certainly in the logger code, which is very fresh and hard to debug. Help appreciated here, as my brain kind of melted during the code-give-birth :/ > Also, curious why waitevent() always sets the event_nr > field of the event_thread structure in multipathd to > the event number value pulled from the kernel for the > mapped device instead of using the event number > currently saved in the event_thread structure? > > While I can see getting the number from the kernel the > first time through the code for each mapped device, I > think the way it is coded it is possible to lose events. > > I think events can get lost if they occur between the > time multipath pulls out the kernel path state for the > affected mapped device for the previously detected event > and the time that the new waitevent pthread calls waitevent > for the same mapped device. Granted, the pthread will > likely make it first -- but there is nothing in place which > makes this so. > Have you tried your suggested design ? Is there a regression at first glance ? > -- > > dm-devel@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/dm-devel -- christophe varoqui <christophe.varoqui@xxxxxxx>
