James Carlson wrote: > John Plocher writes: >> James Carlson wrote: >>> How's that? >> The difference I see is that in the original case, only autofs >> triggered mount points were handled by this code path; in the >> new code allows anything that sets S_TRIGGER will, uhm, trigger >> this code path. >> >> As long as only autofs does it, things are identical. If anything >> else does... >> >> At least, that's how I parsed it. > > That's what appears to me to make it identical. > > If the project team is actually making _more_ file systems set > S_TRIGGER, then I agree that the bug has been crowbared open a bit, > and that might well be enough to push me into the "opposed" camp.
We do plan to use this beyond autofs. That's kinda the point :-) But we think it is identical architecturally. What we're implementing is very much like autofs triggers created under /net. We don't know a priori where they are like we do with the regular automounter maps, but when we need to know, we go look at the server and create nodes on the fly. With /net, we use the MOUNT protocol and parse the output to create triggers. With mirror mounts, we use the NFSv4 "server namespace" support to create triggers by noting changes in the fsid. We can do this better and in more cases with mirror mounts, but it's not different in the end goal. Rob T
