> -----Original Message----- > From: Christophe Varoqui [mailto:christophe.varoqui@xxxxxxx] > Sent: Sunday, November 12, 2006 6:38 PM > To: goggin, edward > Cc: dm-devel@xxxxxxxxxx > 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? 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. > > 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? > > Anyway, I'm sorry for keeping you walking in circles there. That's ok. I learned some things and we have a better solution now. Thanks for your help! > Regards, > cvaroqui > > > > > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
