==> Regarding Re: autofs4 looks up wrong path element when ghosting is enabled; Ian Kent <[EMAIL PROTECTED]> adds:
raven> On Sat, 24 Sep 2005, Jeff Moyer wrote: >> >> >> >> >> Ian, I'm not really sure how we can address this issue >> without VFS >> >> changes. Any ideas? >> >> >> >> >> raven> I'm aware of this problem. I'm not sure how to deal with it yet. raven> The case above is probably not that difficult to solve but if the raven> last component is a directory it's hard to work out it's a problem. >> >> Ugh. If you're thinking what I think you're thinking, that's an ugly >> >> hack. >> raven> Don't think so. >> raven> I've been seeing this for a while. I wasn't quite sure of the source raven> but, for some reason your report has cleared that up. >> raven> The problem is not so much the success returned on the failed mount raven> (revalidate). It's the return from the following lookup. This is a raven> lookup in a non-root directory. I replaced the non-root lookup with raven> the root lookup a while ago and I think this is an unexpected side raven> affect of that. Becuase of other changes that lead to that decision raven> I think that it should be now be OK to put back the null function raven> (always return a negative dentry) that was there before I started raven> working on the browable maps feature. >> raven> I'll change the module I use here and test it out for a while. If raven> you have time I could make a patch for the 2.4 code and send it over raven> so that you could test it out a bit as well. >> Just send along the 2.6 patch, since I have to deal with that, too. >> I'll go through the trouble of backporting it. raven> I'm in the middle of working on lazy multi-mounts atm so I'm not in raven> a good position to test. It's a little tricky so I don't want to raven> forget where I'm at by getting side tracked. raven> But here's the patch that I will apply to my v5 tree for the initial raven> testing. Hopefully you will be able to give it a run in a standard raven> setup. I put together a different patch, but I want to get your input on the approach before I post it. It requires both user-space and kernel-space changes. Basically, you identify that a given automount tree is a direct map tree. This information is passed along to the kernel (I did this via a mount option), and recorded (in the super block info). Then, when a directory lookup occurs, if we are in a direct map tree, and ghosting is enabled, then we pass the lookup on to the real lookup code. I'm not sold on the approach, as I haven't thought through all of the implications. Care to comment? -Jeff _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
