On Tue, 2017-09-05 at 22:44 +0000, Trond Myklebust wrote:
> > On Sep 5, 2017, at 18:31, Kjetil Joergensen <kjetil@xxxxxxxxxxxx>
> > wrote:
> >
> > Hi,
> >
> > On Tue, Sep 5, 2017 at 10:51 AM, Weston Andros Adamson <dros@monkey
> > .org> wrote:
> > > I chatted with Trond about this and he says it's a server bug if
> > > an unlinked file
> > > keeps stateids around - the client doesn't need to issue a close
> > > in this case.
> >
> > We don't disagree that this is a bug with the server, it is after
> > all
> > a rather efficient
> > denial-of-service attack against it (Especially if you don't
> > dismantle
> > your clients
> > all that often).
> >
> > Although, not calling CLOSE under certain circumstances doesn't
> > seem correct.
> >
> > Continuing to cherrypick from RFCs:
> >
> > RFC5661 - 8.2.4. Stateid Lifetime and Validation
> > Stateids must remain valid until either a client restart or a
> > server
> > restart or until the client returns all of the locks associated
> > with
> > the stateid by means of an operation such as CLOSE or
> > DELEGRETURN.
> > If the locks are lost due to revocation, as long as the client ID
> > is
> > valid, the stateid remains a valid designation of that revoked
> > state
> > until the client frees it by using FREE_STATEID.
> >
> > > What version of ONTAP are you running?
> >
> > Version: NetApp Release 8.2.4P6 7-Mode: Wed Jan 11 01:07:08 PST
> > 2017
> >
> >
>
> We’re not fixing any server bugs on the client, and this is
> definitely a server bug. You can’t have state associated with a non-
> existent or completely inaccessible file.
>
Concerning your quote there about FREE_STATEID, that has nothing to do
with deleted files. It is a mechanism to allow the server to safely
cache open state in the particular case where a network partition
prevents the client from renewing its lease. There is nothing that says
it applies to deleted files, and nor is there any reason why we would
want to cache open or lock state in a case where the filehandle is
stale.
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@xxxxxxxxxxxxxxx
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
