Subject: RE: What does paragraph 1 of Section 8.9 mean?

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 13 Mar 2001 12:20:26 -0800

Tom Talpey wrote: 
> At 06:23 PM 3/12/2001, David Robinson wrote:
> >If we simply allowed a new OPEN 
> >flag to indicate "advisory locking" we could dispense with 
> >the magic stateids. In fact, the only way the client could 
> >perform I/O operations would be to have a valid stateid 
> >which would make the requirement to use OPEN implicit.

> This seems clearly the best way out of the situation. Especially for
> stateid 0 which can be argued as unnecessary. But for stateid -1,
> I'm not sure the goal is to get an advisory lock. It's more of a "don't
> care". In this case, the server can manufacture a don't care stateid
> of its own choosing and the client can proceed.

Eliminating the special stateid's can simplify the spec.

Another advantage of doing the definition of any special handling
in OPEN (and leaving the choice of the stateid to represent that
special handling to the server) is that it is more expandable.

We may not have heard the end of special open or locking options,
if experience is any guide.  If we go down the special stateid route
for those, some future minor version might have -2, -3, etc. as
special stateid's, which is *ugly*.  On the other hand, if do those
future options through OPEN, then -1 remains forever as an isolated
and wierd exception.

Let's let the opaque stateid be opaque.

I suspect some people will need the functionality currently provided
by stateid -1 (doing IO's, any locks notwithstanding), so let's
provide it by making it an option in OPEN, although with the same caveat
that applies to the stateid of -1: the server can reject the request 
if he cannot support that mode of operation.

---

From: "Sergey Klyushin" <[email-masked]>
Date: Tue, 13 Mar 2001 15:58:19 -0500

> -----Original Message-----
    > From: Noveck, Dave [mailto:[email-masked]]
    > Sent: Tuesday, March 13, 2001 3:20 PM
    > To: Talpey, Thomas; David Robinson
    > Cc: [email-masked]'; Lent, Arthur; Wittle, Mark
    > Subject: RE: What does paragraph 1 of Section 8.9 mean?
    >
    >
    > Tom Talpey wrote:
 What OS will need it? Windows doesn't.

---

From: David Robinson <[email-masked]>
Date: Tue, 13 Mar 2001 13:36:11 -0800

>  What OS will need it? Windows doesn't.

Unix, the fear is some client will mandatory lock a critical
file and cause applications to fail.  It is also expected that
some applications (/bin/cat) will want to allow reading of a file
regardless of what another application sets the locks to be.

	-David

---

From: Brent <[email-masked]>
Date: Tue, 13 Mar 2001 15:51:10 -0800

> if he cannot support that mode of operation.

Argh! I think OPEN already sets the world's record for the most
complex piece of XDR.  Let's stop adding stuff to OPEN.

We could make this a lot simpler if we just added
another simpler op that could be inserted before
an OPEN to control some characteristics of the OPEN.

I'm also thinking ahead to minor version extensions.
Additional ops that "prime" the open would be much
easier to add, than to tack more stuff onto OPEN.

Let's make compound ops work for us ...

	Brent

---

From: David Robinson <[email-masked]>
Date: Tue, 13 Mar 2001 16:11:08 -0800

> an OPEN to control some characteristics of the OPEN.

You think it is simplier to add a new Op, then to add
a new ACCESS4_IGNLOCK flag?

> easier to add, than to tack more stuff onto OPEN.

Hopefully implementions are ignoring the unused bits in the
flag fields, so defining a new bit is very cheap and easy.

> Let's make compound ops work for us ...

Because we never defined compound ops to be atomic, we
are stuck with heavyweight ops for the things like open
that expect atomic semantics.

But then I never liked compound ops...

	-David

---

From: "Neil F. Brown" <[email-masked]>
Date: Wed, 14 Mar 2001 14:24:22 +1100 (EST)

> a new ACCESS4_IGNLOCK flag?

I thought that the point was that Open is too complex as it is.  Any
suggestion to add more to Open is proof-positive that it is too
complex, so let's take it as an impetus to fix Open.

> But then I never liked compound ops...

no imagination :-)

I have this vision for how Open could work.  Allow me to try to paint
if for you.
We would need:

   A way to pass state-cookies between OPs in a compound much like we
     can pass filehandles. Call it (csc) for Current State Cookie.
     I will assume that a (csc) can in some cases identify a file, so 
     a filehandle is not always needed.
   A little bit more structure in the COMPOUND - as well as
     sequence-but-exit-on-failure, we need a "finally" concept so that
     some ops get executed even if previous ones fail.  This was
     mentioned by Brent ages ago I think.
   A few more OPS (to replace bits of open):

    LOCK_NAME 
      (cfh) (csc) filename access deny create-verifier ->
             (csc) access-granted deny-granted 
   
     This locks a name in a directory. The name may not currently
     exist.  access and deny modes come from:

         readopen - open of the named file for READ
         writeopen - open of the named file for WRITE
         create - create an object with the given name
                 This include mkdir, mknod and even link.
         unlink - remove the name. Include rename.

      if readopen or writeopen is denied, then that must apply to
      other links to the file if hardlinks are supported.
      So probably a deny-readopen on a name which doesn't exist would
      need to be accompanied by a deny-create.  The server might grant
      the deny-create even if it wasn't asked for, or it might reject
      the request, I'm not sure.

      The create-verfier would be recorded with the (csc) and stored
      in the inode (or wherever) on an exclusive create.  If a
      LOCK_NAME arrived during the grace period for a name that
      referred to an existing file that appeared to have been
      exclusive-created (i.e. size was 0 etc) and the verifier in the
      file matched the create-verifier, then the server would remove
      the file so a subsequent test and create would do the right thing.

      The server can grant more access or denial than was asked for.
      This is how delegation is done.

    UNLOCK_NAME
        (csc) access deny -> (csc) new-access new-deny
 
      This askes for the lock on the name to be reduced to at most the
      values given.  The response tells what the new access/deny level is.

    CREATE 
        (csc) attributes -> (cfh) (csc)

      Create is given a state-cookie for a locked name and creates
      something there.  

    OPEN
        (csc) access -> (cfh) (csc)
      Opens an existing file.  I'm not sure if CREATE should do an
        implicit open, or if a CREATE; OPEN sequence should be used.
 
    SAVESC, PUTSC, RESTORESC similarto SAVEFH, RESTOREFH
         
Then, for example, an exclusive create wit ACCESS_BOTH, DENY_BOTH might look like:
     
     PUTFH directory-filehandle
     LOCK_NAME "myfile" verifier access(create,writeopen,readopen) deny(create,readopen,writeopen,unlink)
     SAVESC
     VERIFY (type == NOFILE)
     CREATE 0660
     OPEN access_both
     Finally
     RESTORESC
     UNLOCK_NAME access(writeopen,readopen) deny(readopen,writeopen)

  Given this flexability, there would be some combinations that you
  wouldn't expect a server to support. An obvious example is to
  maintain a deny_create lock on a name after a compound op completes
  without creating an object with that name.  It shouldn't be too hard
  to come up with some rules about what a server must, should, and
  could support.

  It also probably makes server implementation a bit more difficult,
  as it might need to do some pattern matching over the whole request
  to see how to implemented it and whether it can be implemented.
  That is probably the biggest obsticle to this approach.

  As mentioned above, delegation would be handled by the server giving
  extra access and, particularly, extra denial in response to a
  LOCK_NAME request.  The extra information that the client gets for a
  delegation, such as space reservation and delgated ACL could be
  fetched separately.  GETATTR couldn't be used as a state-cookie is
  needed, but something fairly obvious could be arranged.

That, then, is my dream for how COMPOUND could be used to break OPEN
into conceptually manageable bits.

Ofcourse, it doesn't address the current issue of over-ridding
mandatory read locks.  This is probably because I don't see mandatory
read locks as an "open" issue in the protocol.
I actually think that mandatory read locks are rather silly.
Mandatory write locks make sense (even if I don't like them) but
mandatory read doesn't.  I really never care if someone else is
reading my file. But they might care that I am writing it.

At the protocol level, I don't think that the server should ever
reject a read request simply because there is some sort of lock on the
file.
Rather, if the client wants to participate in mandatory read locking,
it should encase each read request in a lock, viz:

   PUTSC mystatecookie
   LOCK access_read, byterange
   READ byterange
   UNLOCK access_read, byterange

Then if a read lock is not possible, the read doesn't get tried.

Ofcourse, this needs state-cookies (stateids) to be able to pass
between OPs in a compound too, and that currently isn't possible...

Oh well, maybe in NFSv5 (NFSvV?)

NeilBrown

---

From: Brent Callaghan <[email-masked]>
Date: Tue, 13 Mar 2001 21:46:23 -0800

>      mentioned by Brent ages ago I think.

So that post-op attributes could be returned even in the event of
failure like v3 does. But it was starting to look complex, so I
threw it out.

>   [ breaking up OPEN ]

Some of the OPEN args/results would separate out quite easily
and in hindsight, I think we should have done it.  Though I 
think we still would have been stuck with only a slightly
less messy op. OPEN is what you get when you smoosh UNIX open()
with Win32's OpenFile().

> into conceptually manageable bits.

I'm not sure how your LOCK_NAME & UNLOCK_NAME would map into Win32's
OpenFile().  What limits the extent of an OPEN breakup is the ability
of Win32 servers to implement it.

> Oh well, maybe in NFSv5 (NFSvV?)

Well, there's always minor versions - think NFSv4.1

	Brent

---

From: "Neil F. Brown" <[email-masked]>
Date: Wed, 14 Mar 2001 17:19:49 +1100 (EST)

> of Win32 servers to implement it.

It was actually in the context of trying to understand OpenFile and
the access/deny modes that I first came up with the idea of name
locking.

On a WIN32 system, which does not support hard links, the open/share
concept can be understood in terms of locks on the names in a
directory.

Normally when you OpenFile in WIN32 no other user can open, rename or
remove that file.  You need to explicitly state that certain accesses
are "shared".  You can share "openread" and "openwrite", but not
"unlink/rename" I think.

When you try to extend this idea to a filesystem that supports hard links,
you have to treat "deny_read" and "deny_write" as applying to the file
and not just to the name, but without hard links, it really is a name
locking thing, while record locks are a data locking thing.

I would imagine a server written on-top of a WIN32 interface requiring
that a LOCK_NAME be followed very closely by an OPEN and would combine
the two into one OpenFile operation.  An intervening VERIFY that
checks for the existance of the file followed by a create would be
allowed, but that would be all.
Further, a LOCK_NAME would report that DENY_UNLINK have been provided
as well, even if it hadn't been asked for.

NeilBrown

---

From: Carl Beame <[email-masked]>
Date: 15 Mar 2001 12:26:01 +0000

> concept can be understood in terms of locks on the names in a

Sorry, Under NTFS hard links ARE supported! Check ouy the MKS program
ln.exe

- Carl

---

From: Neil Brown <[email-masked]>
Date: Tue, 20 Mar 2001 12:44:41 +1100 (EST)

> Sorry, Under NTFS hard links ARE supported! Check ouy the MKS program

Fair enough.... just confirms that the best way to cure ignorange is
to expose it :-)
Thankyou.

So, is it still true that you cannot remove a file which someone else
has open?
If so, and I have open a file which has two links, can neither link be
removed, or is it only the link that I used to open the file that
cannot be removed?

NeilBrown