Aren't sequence slots shared by the same open owners? The problem I'm seeing is that a client with an outstanding open can't respond to a delegation return because sequenced hasn't been confirmed. I think it's problematic when there are two clients each holding delegations and each sending an open. The server tries to recall the delegations but neither clients will reply until the server returns an open to the outstanding open. The server will try and not reply to the outstanding opens until the delegations are returned. On Mon, Oct 6, 2014 at 9:57 AM, Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote: > Hi Olga, > > On Mon, Oct 6, 2014 at 9:48 AM, Olga Kornievskaia > <olga.kornievskaia@xxxxxxxxx> wrote: >> The spec says that open owner needs to be different for different >> files yet the code returns the same value. >> >> It is not clear to me what's broken about ida_get_new() that's used >> for generation of the owner ids. >> >> Can somebody comment on this? >> > > As far as I know, there is no requirement in either NFSv4 or NFSv4.1 > that open owners be different for each file. In NFSv4.1 there is a > requirement that they be unique to each credential/principal, but only > if you negotiate EXCHGID4_FLAG_BIND_PRINC_STATEID. > > The current choice of scheme where we share open_owners between files > was largely motivated by a desire not to overload the NFSv4.0 servers > with lots of open_owner structures. In NFSv4.0, those structures are > required to be cached by the server for a while after the file has > been closed. > > Cheers > Trond > > > -- > 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
