Subject: Esoterica (Was append writes)

From: Neil Brown <[email-masked]>
Date: Tue, 20 Mar 2001 13:56:19 +1100 (EST)

I have two reponses to the thread about append writes and whether we
realy need them or whether they are esoteric and the same
functionality can be achieved better with some different method
(e.g. syslog).

The first response is:

  Yes: let's keep all the esoteric stuff out of the NFS protocol.  It
  isn't really needed, and there are other ways to achieve the same
  goals that keep NFS simpler.
 
  Examples:
    1/ append write.  We seem to have lived with out it, and people
    should use syslog instead.

    2/ exclusive create.  NFSv2 did just fine without it.  People
    found that 
       create(uniq-name)
       link uniq-name shared-name
    had the same effect and worked fine in NFSv2.  So we really don't
    need exclusive create.

    3/ record locks.  99.9% (rough guess) of nfs accesses do not use
    locking, so that makes it pretty esoteric.  And advisory locks are
    just a form for IPC (plus a little bit of cache control) so get
    applications to be honest about their need for IPC (instead of
    just pretending and using locks) and use ONC/RPC or whatever is
    appropriate. 
    Just as append write can be done adequately with a separate
    protocol (syslog) locking can be done adequately with a separate
    protocol...  No, wait, we tried that.  It was called NLM...

  I really don't see that the argument in importantly different
  between these three.  They are all esoteric.  They are all hard.
  They are all needed if we are too make NFS look like a real
  filesystem.

  Rather than focus on the esotric, lets focus on the real, every day
  issues. What are they?
  Well, at my site, which may not be typical, but isn't too atypical I
  think, the two ways in which users notice NFS (and I would rather
  they didn't notice, it should just work) are .nfs files and speed.

  We fairly regularly have users complain they they have this
  ".nfsXXX" file in their directory and that if they remove it, it
  just comes back with a different name.
  I finding it very disappointing that NFSv4 didn't remove the need
  for this, despite the fact that the server now has enough knowledge
  about the state of clients to hide the need completely.

  Speed is something that is being addressed quite well, and this is
  good.  Unstable writes in v3 and delegations in v4 should go a long
  way to improving speed, though it would be nice if file creation
  could be delegated too. Maybe in v4.2...
  It is delegation that most attracts me to v4.

My second response is:

   Yes, you could implement logging via syslog or similar, instead of
   append-write, but then you loose the advantages of NFS:

     1/ uniform naming.  Syslog has about 8 (or 16?) FACILITIES and
        about as many severity levels.  NFS file naming allows for
        arbitrary hierarchical naming schemes.

     2/ authentication.  syslog would use nothing more than
         reserved-port authentications.  NFS can (will in v4) give you
         proper crypto security.  It would be a lot of work to add the
         same to syslog

     3/ multiple users. This is really a special case of 1+2.
         With NFS, each user can do their own logging independantly of
         others and of root.  With syslog some co-ordination would be
         needed if it were possible at all.

   Certainly all of this could be added to GnuSyslog, but why bother
   when we have it in NFSv4?

In summary, if O_APPEND is a valid filesystem operation it should be
supported by NFSv4, and if not it should be removed from POSIX.

NeilBrown