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@xxxxxxx] > Sent: Monday, November 13, 2006 5:38 PM > To: goggin, edward > Cc: dm-devel@xxxxxxxxxx > 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@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? > > > 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 > > > > > > > > > > > > > > > > > > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
