Matt Taggart wrote: > Poking around in the autofs userspace package, it looks like the > daemon tells the kernel the max version of autofs it knows how to > talk(AUTOFS_MAX_PROTO_VERSION) which is set to 4. So if both are built > in it should use v4. Is that not the behavior you're seeing?
No. I am seeing different behavior. Looks like 'autofs' behavior. I can't _really_ tell which driver is being used. As a module I can 'lsmod'. But how do you tell if it is not a module? But the behavior is matching 'autofs' behavior so I am assuming that is the one being used and not 'autofs4'. I believe autofs4 is also needed for NFSpv3 support. Otherwise you just get NFSpv2. But don't quote me on that. In any case, I think autofs4 should be the default. It is not in the 686 kernel either but both are modules so it can be selected easily enough. > Anyway /usr/share/doc/autofs/README.Debian says, > > "You will need to have the AUTOFS4 filesystem compiled as a module for > your kernel." I assume that means either as a module or as compiled into the kernel. I think they really just mean selected for your kernel. It needs wordsmithing. (BTW, I don't see that documentation with the current version of autofs in stable.) > Is there any reason to have the compiled in? (I guess you could ask > if there's any reason to _not_ have these compiled in, but I'm not > in that camp) I can't think of any reason. Obviously I would prefer it as a module because then I would not be having this issue. Just to be clear, this is Bdale's kernel-image-2.4.19-mckinley-smp from debian.org and it is compiled it in, not a module, for the stock Debian kernel. So I can't answer why it is that way. I would guess that it has not been made visible as an issue until now. Bob
