On Tue, May 03, 2016 at 04:31:19PM +0100, Germano Percossi wrote: > Hi, > > Sorry for jumping in the middle of patch review > > On 05/03/2016 03:27 PM, Benjamin Marzinski wrote: > >On Tue, May 03, 2016 at 07:57:01AM +0200, Hannes Reinecke wrote: > >>On 05/02/2016 06:26 PM, Benjamin Marzinski wrote: > >>>On Wed, Apr 27, 2016 at 01:10:29PM +0200, Hannes Reinecke wrote: > >>This is primarily for co-operation with udev. > >>As we typically do _not_ use multipath for creating device-mapper tables > >>the synchronisation problem between multipath and multipathd > >>doesn't typically occur. > >>At least not for us :-) > > > >Well, it doesn't occur for us either, unless someone runs multipath at > >EXACTLY the wrong time, at which case, I'm pretty sure the same thing > >can happen in any distro. The question is, do we protect against that > >very unlikely occurance. The only time I see this actually having any > >real chance to occur would be if some multipath user writes a script > >that listens for new devices to be discovered, and then *helpfully* runs > >multipath to update the system. I have seen this. Multiple times, in > >fact. I'm not sure how much work we need to expend saving these people > >from themselves, however. > > > > I just want to make sure XenServer is not among those that need to > be saved from themselves. > We do mix multipathd and multipath commands but in a way that we think > is safe: we add devices with "multipath -r" and remove with "multipath -f". > This is because we slightly bend the wwids file usage to be used > as a blacklisting mechanism (in our own way). The only way you would be likely to run into problems is if you would be running "multipath -r" at the same time as the udev add event for the first path device was happening. We only lock the devices on the initial create. But doesn't multipathd try to add these devices too? -Ben > I am wondering if removing cooperation between multipath and multipathd > is going to cause us troubles in the future. > > Regards, > Germano > > -- > 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
