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

[Christophe Varoqui]

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
> > 
> > 
> > 
> > 
> >