On Tue, 2009-07-21 at 11:32 -0700, Ben Greear wrote: > On 07/21/2009 11:28 AM, Trond Myklebust wrote: > > On Tue, 2009-07-21 at 11:01 -0700, Ben Greear wrote: > >> On 07/21/2009 10:59 AM, Trond Myklebust wrote: > >>> On Tue, 2009-07-21 at 10:36 -0700, Ben Greear wrote: > >>>> On 07/21/2009 10:12 AM, Trond Myklebust wrote: > >>>>> On Tue, 2009-07-21 at 09:49 -0700, Ben Greear wrote: > >>>>>> On 07/21/2009 05:15 AM, Trond Myklebust wrote: > >>>>>> > >>>>>>> What does /var/lib/nfs/v4recovery look like on the server? > >>>>>> The server was misconfigured, but I still think the client should > >>>>>> behave better in this case. If you cannot reproduce it, let me know > >>>>>> and I can try to be more specific. If you still want the v4recovery > >>>>>> information, let me know and I'll send it. > >>>>> So how should the client behave, when a screwed up server allows it to > >>>>> mount but starts returning illegal values for setclientid? The only > >>>>> thing I can see we could do is to tell the user EINSANESERVER... > >>>> Well, it could just fail the mount and give up and not overly spam > >>>> /var/log/messages in a tight loop perhaps? > >>> This doesn't happen at mount time. It happens when you open a file. > >> Not for me, and evidently not for the other person that reported > >> similar results. All I had to do was attempt the mount (which never > >> completed). > >> > >> Thanks, > >> Ben > > > > Ah... You have NFS_V4_1 enabled despite the Kconfig warning... Does the > > bug occur when you turn this off too? > > Yes, it did. OK. Then the NFSv4.1 merge has screwed up the state management. We do NOT want to hold client id state on the server when there is no file state... Trond -- 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
