Ewan Mac Mahon wrote: > On Mon, Oct 26, 2009 at 02:06:45PM -0400, Steve Dickson wrote: >> On 10/26/2009 01:34 PM, Frank Ch. Eigler wrote: >>> Steve Dickson <SteveD@xxxxxxxxxx> writes: >>> >>>> On 10/26/2009 12:06 PM, Frank Ch. Eigler wrote: >>> Unfortunately, this sounds like "only". Is it out of the question to >>> make the client look for this case (an upgraded client in an existing >>> unupgraded, unchanged network) and handle it? >> We talked about it... See http://linux-nfs.org/pipermail/nfsv4/2009-October/011471.html >> >> But in the end, I decided not to do this since its not clear how the change >> would interact with other NFS servers... >> > It's not clear to me how falling back to NFSv3 if v4 fails (and the > version wasn't explicitly set to v4) could ever cause a problem - it > might not help, but under what circumstances could it possibly be > harmful? I had a look at the linked thread from linux-nfs and no-one > there seemed to come up with anything concrete. The strongest objection I found was > Older versions of ONTAP (like 6.0 through 6.2?), for example, have the > same problem as the Linux NFSv4 server does currently, iirc. > > It's also worth noting that modern Solaris clients do not have this > ENOENT workaround. So, if automounter maps are shared with Linux > clients _with_ the workaround, mounting a Linux NFSv4 server, there > may be some issues. > > In the long term, I think we are much better off living with a few > months of complaints about the new version negotiation behavior, > rather than having this mount.nfs workaround. I'm not going to object > to it outright, though... (chuck[dot]lever[at]oracle[dot]com) "I'm not going to object outright" sounds to me like we can fall back to V3. I think this is the best plan for us: we should not break things for users of Fedora clients with RHEL servers or Fedora clients with Fedora servers. Further, > On Oct 22, 2009, at 10:04 AM, Steve Dickson wrote: > > On 10/22/2009 12:21 PM, Chuck Lever wrote: > >> This would be mitigated instantly by leaving the version negotiation > >> default set to v3/v2. Then no workaround would be needed. > > Right... Or defining the negotiation in the configuration file > > would also cause the workaround not to be needed... > > That's what I meant: set defaultvers: 3 in the config file, and allow > early adopters to change it. After a while, we can bump the default > setting. I think this is roughly what Sun did during their transition. (chuck[dot]lever[at]oracle[dot]com) Leaving the default at Version 3 for the next year or two would mostly solve the problem. Andrew. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
