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

[dm-devel] RE: patch to CLARiiON path checker to handle inactive snapshhots



OK, I'll work on it tomorrow and send it to you before
updating the CLARiiON specific checker to use this new
path checker context.

> -----Original Message-----
> From: Christophe Varoqui [mailto:christophe varoqui free fr] 
> Sent: Monday, November 13, 2006 5:38 PM
> To: goggin, edward
> Cc: dm-devel redhat com
> Subject: RE: patch to CLARiiON path checker to handle 
> inactive snapshhots
> 
> Le lundi 13 novembre 2006 à 14:15 -0500, Edward Goggin a écrit :
> >  
> > > -----Original Message-----
> > > From: Christophe Varoqui [mailto:christophe varoqui free fr] 
> > > Sent: Sunday, November 12, 2006 6:38 PM
> > > To: goggin, edward
> > > Cc: dm-devel redhat com
> > > Subject: Re: patch to CLARiiON path checker to handle 
> > > inactive snapshhots
> > > 
> > > Le vendredi 10 novembre 2006 à 18:02 -0500, Edward Goggin 
> a écrit :
> > > ...
> > > 
> > > Ok, I aknowledge this approach is far more complex than your 1st
> > > attempt.
> > > 
> > > If I read correctly the two candidate patches, the clariion 
> > > checker need
> > > to share information with the other path chechers 
> attached to the same
> > > multipath to decide for a state to return.
> > 
> > Yes.  This is only because for the passive paths, the clariion
> > is not returning a specific sensecode/asc/ascq combination to
> > indicate an illegal attempt to read/write from/to an inactive
> > snapshot LU.  If it did so, the clariion path checker code
> > could continue to rely simply on testing each path independently.
> > 
> > By the way, since none of these solutions deal correctly with
> > the use case where /sbin/multipath is checking the path status
> > of a passive path to an inactive snapshot before any active
> > paths to that LU have been checked, /sbin/multipath will show
> > the passive path (or those passive paths) as ready when it
> > (they) are really faulty.  I think the best solution for this
> > is to have the /sbin/multipath (or its equivalent like
> > "multipathd -k") get the path state(s) from /sbin/multipathd
> > instead of re-calculating its own states.  What do you think?
> > 
> It sounds right, and it should be a safe change as long as the "daemon
> startup" and "multipath-without-multipathd" logics are unaffected.
> 
> > Also, what about the idea of the distributions no longer starting
> > /sbin/multipath before /sbin/multipathd in order to avoid cases
> > where multipathing is started without having the full feature
> > set of multipathd (e.g., queue_if_no_path timeout feature).  This
> > is after initrd so there shouldn't be restricted user environment
> > issues involved with providing multipathing for the root device
> > from the ram disk.
> > 
> Yes, /sbin/multipath mostly useful for root-on-san, embeded in
> initramfs. Even there, a single-shot run of multipathd might work.
> 
> > > 
> > > If so, let's pretend another checker might one day stress the same
> > > need :)
> > > 
> > > What do you think of a facility like the following 
> > > (completely untested
> > > and surely semi-bogus) patch sketches ? Would it make 
> your patch as
> > > straight as your first attempt ?
> > 
> > Yes.
> > 
> > > 
> > > It seems to take care of our griefs with "container_of" and the
> > > clariion-centric additions to "struct multipath".
> > 
> > Yes.  I like your idea, it adds generic value whereas my 
> 1st solution
> > did not.  Will you be checking in this code soon?
> > 
> You should build upon it as-is.
> 
> As the first user of the framework, you may want to change it a bit to
> make theory meet reality. Then I'll happily merge it as a preparatory
> patch for the clariion checker bits.
> 
> 
> > 
> > > Regards,
> > > cvaroqui
> > > 
> > > 
> > > 
> > > 
> > > 
> 
> 
> 


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