On Mon, Mar 2, 2015 at 3:53 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > On Mon, Mar 2, 2015 at 3:47 PM, Trond Myklebust > <trond.myklebust@xxxxxxxxxxxxxxx> wrote: >> Hi Olga, >> >> On Mon, Mar 2, 2015 at 3:15 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: >>> Hi folks, >>> >>> I'm experiencing that CLOSE uses a delegation stateid instead of the >>> open stateid which I think is what the spec says. Server replies with >>> BAD_STATEID. >>> >>> Is this a bug or did I misread the spec? Thanks. >>> >> >> That would be a client bug. Do you have a reproducer? > > Yep. Just cat a (2nd) file after mount (i.e.., a file needs to have a > delegation). A CLOSE will use a delegation stateid. Problem is seenl > on the network trace. It will also leads to failure on unmount with > CLIENTID_BUSY because there is still an open state that client never > released. Please note that both "cat" and "unmount" will "succeed" > from the user's perspective. Thus, unless testing also looks at the > network trace, this failure will never be caught. Anna pointed me at the commit 566fcec60. It seems to be that's what broke it as it removed the use of openstateid for the stateid arg. But I really don't understand the necessity of the patch. CLOSE must always use the openstateid. Therefore it doesn't need to worry that stateid is changed from openstateid to delegation stateid or locking stateid. It should just use the openstateid as it did before. > > >> >> -- >> Trond Myklebust >> Linux NFS client maintainer, PrimaryData >> trond.myklebust@xxxxxxxxxxxxxxx -- 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
