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

[Edward Goggin]

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 at free.fr] 
> Sent: Monday, November 13, 2006 5:38 PM
> To: goggin, edward
> Cc: dm-devel at 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 at free.fr] 
> > > Sent: Sunday, November 12, 2006 6:38 PM
> > > To: goggin, edward
> > > Cc: dm-devel at 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
> > > 
> > > 
> > > 
> > > 
> > > 
> 
> 
>