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
