Subject: NFSv4 Locking case study

From: Stevan Steve Allen <[email-masked]>
Date: Thu, 27 Feb 2003 01:28:03 -0800

We were researching the following need and became concerned of any RFC
cutoffs.  If I have missed any cutoffs, comments and suggestions are still
welcomed.

For an application to read or write I/O atomically, all participating
applications must obtain a proper file share or byte range lock prior to
the I/O request.  To ensure well behaved applications, the customer may
restrict access (ACL).

The above implementation has the following deficiencies:

 o Does not provide a public access solution
 o Access Lists may be large (maintenance cost)
 o Trusted applications should be retested
   with each new version (cost)

Case:

Given applications which support byte range, or file share, semantics are
considered well behaved Applications which do not support such semantics
are considered rouge applications according to file access needs of various
customer solutions and platforms.  Such rouge applications may need to be
restricted from access.

File access requirements may describe a server which does not support share
upgrade and expects an exclusive latch to be held around both the read and
write request.   A client wrapping an open, byte range lock or providing
share upgrade requests on behalf of unprotected I/O (i.e. a stateid of all
zeros) may not provide the required semantics as expected from a well
behaved application.  To do so is a challenge given mixed semantics of
various platforms.  As such, there is a need in the protocol for the file
owner (server) to reflect solution/platform file access requirements to the
requesting application layer.  The NFS protocol describes such server to
application communication as servers which may require proper open file
share semantics may return NFS4ERR_OPENMODE improper READs or WRITEs when
mandatory locking is in effect.   For the client, Section 14.2.36. (Write)
describes returning the error to the application as the server may not
support a share upgrade function or attempted the operation and failed. The
"does not support upgrade" describes an permanent application requirement
which could not (should not) be interpreted by the client.

Need:

To ensure proper semantics, range level sharing solutions for performance
may require file share only or stateid of all zeros implementations to be
restricted.  Clients should not interpret this error as re-tryable.  For
reference, the NFSv4 draft mentions similar byte range semantic enforcement
(chpt. 8. "for example, some UNIX-based servers").   We suspect a need for
a specific error to represent this condition.   NFS4ERR_LOCKED is not
appropriate as it signifies a re-tryable condition.  We are proposing an
permanent error to be returned to the application layer.

This approach allows NFS server implementations to enforce needed file or
platform level locking semantics and provides reasonably predictable access
to public files during run time.  (plus catches a few appl bugs).  Given,
performance solutions such as byte range sharing usually limit participants
to similar platforms or products.   We believe this opens up more files and
increases possible NFS solutions with minimal change.

A new return value NFS4ERR_RANGEMODE for I/O type requests is proposed.  An
attribute would also be beneficial.  This is also a file owner enforced
restriction.   Descriptions below.

note: Upon receiving the error, the client should not
    obtain a byte range lock or open and retry the I/O
    request on behalf of the application.  The error
    should be returned to the client application as it
    represents a permanent failure condition (e.g.
    application not well behaved).  If we are past
    cutoff for new errors, what is the proposed
    substitute for nfs4err_rangemode below which
    UNIX based servers should return?

NFS4ERR_OPENMODE existing return
    The client attempted a READ, WRITE, LOCK or
    SETATTR operation not sanctioned by the stateid
    passed (e.g. writing to a file opened only for
    read).

NFS4ERR_RANGEMODE new return
    The client attempted a READ, WRITE, LOCK or
    SETATTR operation not sanctioned by the stateid
    passed (e.g. writing to a file without an exclusive
    byte range lock).

note: the following BYTE_RANGE & FILE_SHARE attributes
    assist clients in identifying locking semantics
    being enforced by the server.  i.e. Useful for
    determining and providing proper delegations.

BYTE_RANGE new attribute
    Application POSIX byte range locking is required.
    The server may not support lock upgrades.
    The stateid of all zeros or ones may not be
    supported.  File share only platforms such as DOS
    and Windows may not be supported.

FILE_SHARE new attribute
    Application open file share semantics are required.
    The stateid of all zeros or ones may not be
    supported. The server may not support open upgrades.

UNSPECIFIED attribute
    This is a courtesy attribute to assist in quickly
    identifying unexpected failures.

    The server has requirements or restrictions not
    reflected in the NFS protocol.  Restrictions may be
    due to platform or product limitations. Servers may
    also impose file usage requirements to address
    customer solutions or file access requirements.
    Refer to the host server documentation for
    additional information.
    (this is the minimal attr proposal being requested)

Question.  OPENs rflags "OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's
file locking behavior supports the complete set of Posix locking
techniques."  I do not believe this indicates I/O requests require
proper<?> byte range locking is required.