Re: [PATCH] multipath-tools: improve processing efficiency for addition and deletion of multipath devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2017-02-17 at 15:41 +0800, tang.junhui@xxxxxxxxxx wrote:
> 
> Hello Ben,
> 
> It's too later now,  I think you'd better go bed, haha.
> 
> > > > The first case should have been reduced to "remove path1 |
> remove path2
> > > > | add path3" by filtering beforehand. I suppose you want to
> avoid this
> > > > sequence because it could leave us without paths temporarily,
> causing
> > > > multipathd to destroy the map. But I don't understand what
> "stop
> > > > merging" buys you here - if you process the events one-by-one,
> you may
> > > > also have 0 paths at some point. 
> > >   
> > > Well, because of the filtering , you will never actually stop
> merging
> > > in this case, like you mentioned.
> >   
> > Or, if I actually read better, I would see that you will stop
> merging.
> > I can't think of any problems in theory with merging adds after
> removes
> > in the simple case at least.
> Maybe we can merger more uevents without stopping mergering(Like
> even 
> merge "add uevent" and "remove uevent" ),  but what I have right now
> handles
> the common cases, which are bursts of add/chage events, and bursts of
> remove
> events. So when we meet the complex scene, we'd better stop
>  mergering, 
> and just let them be processed one by one.  It can reduce abnormal
> situation, 
> and enhance the reliability of the code.

As I wrote in my previous mail, I am not sure if one-by-one processing
is really safer. We are considering a situation where paths for one
WWID are rapidly coming and going at the same time. In that situation
it's inevitable that the kernel and multipathd get out of sync, and
care needs to be taken not to destroy the multipath device prematurely.
 
Because uevents are unreliable and relatively slow, it may actually be
a good idea to pause processing them altogether.

But again, I'm not expecting you to fix this in this patch set. It's
just something we should keep in mind. And it's a good thing that
you're trying not to break stuff :-)

Regards
Martin
-- 
Dr. Martin Wilck <mwilck@xxxxxxxx>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux