On Tue, Aug 31, 2010 at 12:13:20PM -0400, Steve Dickson wrote: > > > On 08/31/2010 11:51 AM, J. Bruce Fields wrote: > > On Tue, Aug 31, 2010 at 11:18:19AM -0400, Steve Dickson wrote: > >> > >> > >> On 08/31/2010 11:13 AM, J. Bruce Fields wrote: > >>> On Tue, Aug 31, 2010 at 11:10:08AM -0400, Jeff Layton wrote: > >>>> I was just pointing out that checking the return code from the system() > >>>> call isn't sufficient. Because of the way most people have modprobe set > >>>> up, it can return an error even though nfsdfs ended up being mounted > >>>> anyway. Checking for the presence of the file after attempting the > >>>> mount would be a more reliable test. > >>>> > >>>> Assuming we're in agreement there, we have another question to > >>>> settle...If the mount attempt fails, what should we do about it? > >>>> > >>>> With my original patch, we fall back to using nfsctl(). You're > >>>> suggesting that we should error out there. I'm not opposed to that, but > >>>> it does mean dropping support for some really old kernels. It also > >>>> means that we can remove some dead code in rpc.nfsd. > >>>> > >>>> OTOH, the fallback might allow nfsd to keep working for some people. > >>>> Maybe it would be better to just log a scary warning and fall back to > >>>> using nfsctl() for now. > >>>> > >>>> In a couple of releases, we could start returning an error there and > >>>> rip out the legacy interface code, or compile it out by default and > >>>> allow people to compile it in via a configure option? > >>> > >>> Yes, let's just add the additional mount attempt for now, and figure out > >>> what to do about the legacy interface as a next step. > >> When the mount fails, I think we should exit... basically eliminating the > >> legacy interface code > > > > Maybe. But as I say, make it two separate steps: > > > > 1. Add code to attempt the mount. > But the question comes do to, what do we do when the mount > fails? It sounds like you are advocating ignoring the error > and allow the nfsd threads to be started via the nfsctl(NFSCTL_SVC) > call... Yes. > I'm advocating that we exit on the mount error, because even thought > the nfsd threads may be set up correctly, the protocols and versions > will not be set up correctly because there is no nfsctl() calls to > set them up correctly... especially with IPV6 enabled... Perhaps so. But that should be done as a *separate* follow-up patch that is clearly labelled "drop support for kernel versions before x.y.z". Dropping backwards compatibility may be a reasonable thing to do, but it's something that we should be very clear about, and that we should put in a patch that does that and nothing else. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
