On Sun, 2018-05-13 at 12:12 +0000, Rick Macklem wrote:
> I wrote:
> > I just ran a little test of an NFSv4.1 server (FreeBSD) reboot
> > while the Linux client
> > had two files open over an NFSv4.1 mount (linux-4.17-rc2).
> > It basically worked, but when I looked at the packet trace in
> > wireshark, it wasn't what
> > I expected.
> > The operations were basically:
> > 1 - ExchangeID
> > 2 - CreateSession
> > 3 - ReclaimComplete
> > 4 - Open/Claim_FH done twice to reclaim the Opens
> >
> > This seems "unsafe" to me, since I think it would be possible for
> > another client to >Open the file with OPEN_DENY_BOTH between #3 and
> > #4, causing #4 to fail.
> > I was expecting something like:
> > 1 - ExchangeID
> > 2 - CreateSession
> > 3 - Open/Claim_previous done twice to reclaim the Opens
> > 4 - ReclaimComplete
>
> I forgot to mention that this is probably not a serious issue right
> now, since most
> extant clients (FreeBSD and Linux I think?) always do Opens with
> OPEN_SHARE_DENY_NONE.
> The only current client I am aware of that does OPEN_SHARE_DENY_xx
> other than
> NONE is the ESXi 6.5 client. Btw, this client has serious issues that
> I might post here, so the Linux server maintainers are aware of them.
>
Hi Rick,
The Linux client will attempt to reclaim opens correctly (i.e. before
sending RECLAIM_COMPLETE). However it will not attempt to reclaim any
lock state if the server advertises a different identity after the
reboot (see RFC5661, section 8.4.2.1.). Are you certain that the
FreeBSD server is advertising the same eir_server_owner and
eir_server_scope fields after the reboot?
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@xxxxxxxxxxxxxxx
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
