From:   "Frank Filz" <ffilzlnx@mindspring.com>
To:     "'Olga Kornievskaia'" <aglo@umich.edu>,
        "'Andrew J. Romero'" <romero@fnal.gov>
Cc:     <linux-nfs@vger.kernel.org>
References: <YQBPR01MB10724B629B69F7969AC6BDF9586C89@YQBPR01MB10724.CANPRD01.PROD.OUTLOOK.COM> <YQBPR01MB10724AEE306F99C844101EED086CF9@YQBPR01MB10724.CANPRD01.PROD.OUTLOOK.COM> <YQBPR01MB10724F79460F3C02361279E8686CF9@YQBPR01MB10724.CANPRD01.PROD.OUTLOOK.COM> <654e3b7d15992d191b2b2338483f29aec8b10ee1.camel@kernel.org> <YQBPR01MB10724B36E378F493B9DED3C7E86D39@YQBPR01MB10724.CANPRD01.PROD.OUTLOOK.COM> <3c02bd2df703a68093db057c51086bbf767ffeb1.camel@kernel.org> <YQBPR01MB1072428BC706EE8C5CC34341186D39@YQBPR01MB10724.CANPRD01.PROD.OUTLOOK.COM> <936efa478e786be19cb9715eba1941ebc4f94a1b.camel@kernel.org> <SA1PR09MB75521717AA00DCAD6CAB5118A7D39@SA1PR09MB7552.namprd09.prod.outlook.com> <CAN-5tyFro=naMgub9uAZ0wa20WhZwV2Rh6xv_meNice1EG+Dug@mail.gmail.com>
In-Reply-To: <CAN-5tyFro=naMgub9uAZ0wa20WhZwV2Rh6xv_meNice1EG+Dug@mail.gmail.com>
Subject: RE: Zombie / Orphan open files
Date:   Tue, 31 Jan 2023 10:18:55 -0800
Message-ID: <046e01d935a0$7b3a2d30$71ae8790$@mindspring.com>
MIME-Version: 1.0
Content-Type: text/plain;
        charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-us
Thread-Index: AQHKHeKiOFZ2WRsyrUPH+SLMUFdhGAMJermdAk/uKvkBsYTADAE8xzQBATE5vK8BW2v3PgLMDpYtAf9tvNsAuV3PQK5UOZ/g
Precedence: bulk

> On Mon, Jan 30, 2023 at 5:44 PM Andrew J. Romero <romero@fnal.gov> =
wrote:
> >
> > Hi
> >
> > This is a quick general NFS server question.
> >
> > Does the NFSv4x  specification require or recommend that:   the NFS =
server,
> after some reasonable time,
> > should / must close orphan / zombie open files ?
>=20
> Why should the server be responsible for a badly behaving client? It =
seems like
> you are advocating for the world where a problem is hidden rather than =
solved.
> But because bugs do occur and some customers want a quick solution, =
some
> storage providers do have ways of dealing with releasing resources =
(like open
> state) that the client will never ask for again.
>=20
> Why should we excuse bad user behaviour? For things like long running =
jobs
> users have to be educated that their credentials must stay valid for =
the duration
> of their usage.
>=20
> Why should we excuse poor application behaviour that doesn't close =
files? But in
> a way we do, the OS will make sure that the file is closed when the =
application
> exists without explicitly closing the file. So I'm curious how do you =
get in a state
> with zombie?

Don't automatically assume this is bad application behavior, though it =
may be behavior we don't all like, sometimes it may be for a reason. =
Applications may be keeping a file open to protect the file (works best =
when share deny modes are available, i.e. most likely a Windows client). =
Also, won't an executable be kept open for the lifetime of the process, =
especially if the executable is large enough that it will be paged =
in/out from the file? This assures the same executable is available for =
the lifetime of the process even if deleted and replaced with a new =
version.

Now whether this kind of activity is desirable via NFS may be another =
question...

Frank