From: Sergey Klyushin (Sergey.Klyushin@hummingbird.com)
Date: 09/25/01-09:47:56 AM Z
From: "Sergey Klyushin" <Sergey.Klyushin@hummingbird.com>
Subject: RE: open/remove sequence
Date: Tue, 25 Sep 2001 10:47:56 -0400
Message-ID: <GGEOLDPPPFAMIJEOBJIBOEGBDBAA.Sergey.Klyushin@hummingbird.com>
> -----Original Message-----
> From: Spencer Shepler [mailto:shepler@eng.sun.com]
> Sent: Monday, September 24, 2001 9:42 PM
> To: Sergey Klyushin
> Cc: nfsv4-wg@sunroof.eng.sun.com
> Subject: open/remove sequence
>
>
>
> Sergey,
> It seems, from your description, that the windows functionality is
> different from Unix in that when a Unix application removes the open
> file, it is removed from the namespace. An open() can then succeed
> with the same name as the removed file without restriction with
> respect to the impending close() of that removed file.
> Also from your description, the windows client can emulate
> everything about remove on close except for failing OPENs from other
> clients. Have you found that this set of options is used often in
> windows?
I'll ask Dan to comment his Client implementation
> Since we seem to have this fundamental difference it isn't clear to
> me which (if either) piece of functionality we should attempt to
> provide.
> Should we provide the simple functionality that David has suggested?
> I am not sure that many server's will implement it. Should we wait
> until a minor version to consider adding a more complex REMOVE op?
>
> Spencer
David's scenario (simple):
1. Client (C1) OPENs file
2. Client (C1) asks to REMOVE file
3. Server refuses to REMOVE OPENed file
4. Client (C1) renames file to .nfsxxxx (question of non volatile file
handle)
5. ANOTHER client (C2) asks to REMOVE .nfsxxxx (without OPEN)
6. Server refuses, because file is OPENed
7. Client C2 has no idea why REMOVE failed (possible to solve with C1
SETATTR 000 after RENAME,
but C2's request still may come between RENAME and SETATTR)
Another one:
1. Client (C1) OPENs file
2. Client (C1) asks to REMOVE file
3. Server refuses to REMOVE OPENed file
4. Client (C1) renames file to .nfsxxxx (question of non volatile file
handle)
5. ANOTHER client (C2) asks to OPEN .nfsxxxx -> Server responds OK
5. Client (C2) asks to REMOVE .nfsxxxx
6. Server refuses, because file is OPENed
7. C2 RENAMEs .nfsxxxx to .nfs1xxx
8. C1's LOOKUP for .nfsxxxx will fail
8. C1 CLOSEs file using file handle
9. C1 asks to REMOVE .nfsxxxx. Get's back to such file (by name,
but by file handle file still exists -> possible caching problem)
One more:
1. Client (C1) OPENs file
2. ANOTHER Client (C2) RENAMEs file to new_file_name
3. Client (C1) asks to REMOVE file -> failed: file_not_exists. C1 can't do
REMOVE on CLOSE
Almost the same behavior if Server allows REMOVE of OPENed files and makes
RENAME trick locally
Another big question when local OS REMOVEs OPENed file.
>From my opinion this approach was fine for NFS v2 and v3, when we did not
have OPEN procedure, but with NFS v4
we may protect ourselves with OPEN operation.
As you said the Client is the one who knows if OPENed file could be REMOVEd,
but Server has no idea about Client's
intention
Windows scenario:
Client wants to use file as temporary, remove it on close and does NOT allow
another clients to remove it
1. Client (C1) OPENs file with DENY_REMOVE, REMOVE_ON_CLOSE (add flags to
NFSv4 protocol)
2. ANOTHER client (C2) asks to REMOVE file -> gets back ERROR, that could be
translated to upper level as ERR_DENIED
3. C2 may OPEN file (question of SHARE mode)
4. C2 can't CREATE file with the same name (file exists and it's true)
5. C1 CLOSEs file
6. Server REMOVEs file
Client wants to use file and does allow another clients to remove it
1. Client (C1) OPENs file WITHOUT DENY_REMOVE
2. ANOTHER client (C2) asks to REMOVE file -> gets back OK or
OK_WILL_BE_DELETED_ON_LAST_CLOSE
3. C2 may OPEN file (question of SHARE mode)
4. C2 can't CREATE file with the same name (file exists and it's true)
5. C1 CLOSEs file
6. Server REMOVEs file
The problems
1. OK_WILL_BE_DELETED_ON_LAST_CLOSE
2. REMOVE_ON_CLOSE state should survive reboot on Server
>From my opinion, Windows approach has less problems
Sergey
>
> On Mon, Sergey Klyushin wrote:
> > Here is how OpenFile/CreateFile works on Windows (locally):
> > 1. OpenFile/CreateFile has one more share attribute
> FILE_SHARE_DELETE
> > 1.1 If file is opened WITH FILE_SHARE_DELETE, than request
> from ANOTHER
> > application to REMOVE file will succeed.
> > File won't be removed immediately, but will be removed on
> the last CLOSE
> > request.
> > New OPENs will fail (with exception OPEN to DELETE).
> > File still will be listed in directory
> > Attempt to create file with the same name will fail.
> > 1.2 If file is opened WITHOUT FILE_SHARE_DELETE, than
> request from ANOTHER
> > application to REMOVE file will FAIL.
> >
> > 2. OpenFile/CreateFile has lots of flags one of which is
> > FILE_FLAG_DELETE_ON_CLOSE (kind of intention OPEN,REMOVE,READ)
> > If this flag is specified at OPEN/CREATE, than file be
> deleted on last
> > CLOSE.
> >
> > 3. File has attribute DELETE_PENDING, that explains
> application why it could
> > not be OPENED other than for deleting.
> >
> > I am trying to implement NFS as much close to local (Windows) OS as
> > possible, but some operations could not be
> > implemented. I understand that NFS protocol can't cover all
> OSs, but if we
> > could cover as much local OSs as possible,
> > we'll benefit it later.
> >
> > Sergey
> >
> > > -----Original Message-----
> > > From: Noveck, Dave [mailto:Dave.Noveck@netapp.com]
> > > Sent: Sunday, September 23, 2001 1:11 PM
> > > To: 'David Robinson'; nfsv4-wg@sunroof.eng.sun.com
> > > Subject: RE: Issues list for RFC3010
> > >
> > >
> > > This isn't exactly what you were asking about, but I think
> > > there is a case in which your approach would require some
> > > identification of who is doing the remove, at least to the
> > > clientid granularity.
> > >
> > > Consider a file which is opened by processes on two different
> > > clients, A and B. Now suppose A does a remove and the
> > > server does not support a delete on last close mechanism
> > > to it returns NFS4ERR_NO_CAN_DO_USE_THE_OLD_HACK_PLEASE.
> > > So client renames the file. Now the application on A
> > > does a close so it now removes the file. But the server
> > > knows that the file is open and would return that same
> > > NFS4ERR_NO_CAN_DO_USE_THE_OLD_HACK_PLEASE and the client
> > > has no way of dealing with that that since he has no way
> > > of knowing when the global last close will occur and, by
> > > hypothesis the server can't do the remove at the appropriate
> > > time either. And further there is no way for the client to
> > > force the remove immediately either.
> > >
> > > If the REMOVE had a clientid parameter, the server could only
> > > check opens for that client and return HACK_PLEASE only if
> > > the file were opened by that client. Then, in the example
> > > above, the file would actually get removed when it was closed
> > > by A, which would certainly annoy B, but is no worse than what
> > > happens now (i.e in V2 and V3).
> > >
> > > An alternative would be to pass a parameter flag that
> indicates
> > > this is a hack remove,
> this_is_the_hack_so_dont_ask_for_the_hack,
> > > which would also force an immediate remove in this situation,
> > > independent of any opens of the file, unless the
> server dupported
> > > delete on last close.
> > >
> > >
> > > -----Original Message-----
> > > From: David Robinson [mailto:David.Robinson@Sun.COM]
> > > Sent: Friday, September 21, 2001 6:06 PM
> > > To: nfsv4-wg@sunroof.eng.sun.com
> > > Subject: Re: Issues list for RFC3010
> > >
> > >
> > > > But you didn't address the issue when the server
> can support it but
> > > > only in cases that it knows that it is what the client
> > > wants. Suppose
> > > > we have a server (say the win2k server) that will
> disallow REMOVE of
> > > > an OPEN file in the general case. However, it has
> the underlying
> > > > capability to allow the client the OPEN, REMOVE, READ
> > > sequence. Your
> > > > proposal doesn't allow the client a method of
> determining that
> > > > capability. Maybe Sergey can let us know if this
> is what his server
> > > > might do?
> > >
> > > If I understand this correctly, the question is if there
> > > exists a server
> > > that will deny a REMOVE differently depending on if
> the caller was the
> > > one who OPENed the file or not. For example, you can only
> > > REMOVE an OPEN
> > > file if you OPENed it. Sergey, do you know of such a
> case? I don't.
> > >
> > > In any case I would advocate that the server can
> choose to REMOVE an
> > > OPEN file or not based on whatever criteria it wishes
> to use. But
> > > if it allows the REMOVE it MUST follow the failure semantics
> > > previously
> > > described.
> > >
> > > If someone does come up with a weird OS that would
> require us to
> > > use stateid's or other client state, I will advocate
> not allowing
> > > REMOVE of OPEN files.
> > >
> > > -David
> > >
> >
>
> --
>
> - Spencer -
>
>
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:11 AM Z CST