Brian, On Sat, 2026-04-25 at 19:16 +0200, Martin Wilck wrote: > > I just had another look at this patch as I'm working on the checkers > myself, and I have to say that this is something you absolutely > cannot > do, especially not when the checker thread is supposed to run > asynchronously. There's a reason that we pass "struct checker *" to > the > checker threads and not "struct path *", and the code above is a hack > to work around this design decision. > > When you write a checker, you need to think carefully what > information > you actually need, and copy that from "struct path" to the checker > context. Currently, for all checkers except emc_clariion, nothing is > needed except pp->fd and pp->timeout. I understand that the alua > checker needs more context, but that doesn't mean you can simply pass > the entire data structure to the checker, and I believe that an ALUA > can be written so that it needs just a few more fields (if any).
Unless I am mistaken, the only additional property that we need for ALUA is the tpg_id. We need to refactor our inquiry and rtpg code such that it takes only the parameters that are needed (fd, timeout, and tpg_id). It would then be possible to call these functions from checkers with limited context, without the hack to pass "struct path *" to the checkers. The tpg_id of a path will change very rarely, if at all (and we currently do not handle possible changes of the tpg_id in a clever way). We determine the tpg_id() in detect_alua(), and on every call of the alua prioritizer, which is too often, IMO. The kernel re-fetches the tpg only if a LUN is rescanned. For a first attempt of an alua checker, we could simply pass pp->tpg_id to the checker. We might as well try to get the ALUA state from sysfs in order to avoid sending extra RTPGs (see Hannes' previous reply), in which case we'd t need the dev_t to determine the sysfs directory. Regards Martin
