From: boris@ftp.com
Date: 12/06/96-10:54:56 AM Z
From: boris@ftp.com
Date: Fri, 6 Dec 96 08:54:56 PST
Subject: RE: Kick-off discussion
Message-Id: <B-Mailer->961206103213.boris@ntbook>
Hello,
Sorry I could not reply right away.
--- On Mon, 2 Dec 1996 11:06:57 -0800 "Michael R. Eisler"
<michael.eisler@Eng.Sun.COM> wrote:
> query for exported file systems
> -------------------------------
>
> It is proposed that the MOUNT protocol not be used for boot
> strapping NFS Version 4 client/server sessions, and in its
> place, a new procedure, SHAREINFO, be added. The SHAREINFO
> procedure would return the list of exported file systems (by
> path name).
Why not just a READDIR? After all exports are just the directory files.
As the starting point in this READDIR (instead of the Directory
File Handle) we can use the mechanism proposed in the new LOOKUP.
> security flavor negotiation
> ---------------------------
It would be great to create a generic security model that is
based on generic (non uid/gid) Identity, generic Object (server,
file, etc.), and generic Rights.
> compound operations
> ------------------
>
Two of such compound operations that are highly useful for
NT and W95 (as well as for VMS) based clients are combinations
of LOOKUP+SHARE and UNSHARE+LOCK OFF+COMMIT
(name: OPEN and CLOSE).
>Non-UNIX systems
>================
>
> [ Note this section has a PC-centric slant ]
>
> Export inheritance
> ------------------
> The NFS protocol is specified to not let a NFS client cross
> mount points. This is so the NFS client does not get confused
> about the identity of files in the even two files on two
> different server file systems share the same file id (inode #).
>
> This semantic is not desired by some clients, such as PC desk tops.
> The proposal, as described previously, is to make
> mount point crossing optional.
The main advantage of NFS (compared to SMB) is its heterogeneous nature.
Things like 'inode #' that can confuse clients and 'mount points'
directly contradict this nature.
About crossing mount point: if shares are treated as simple files growing
from a known root, the problem of crossing mount points goes away.
Let say we have two exports on the system:
adsk:[dir1.dir2] (/adsk/dir1/dir2)
bdsk:[foo.goo] (/bdsk/foo/goo)
the request adsk:[dir1.dir2]\..\bdsk:[foo.goo] (/adsk/dir1/dir2\..\/bdsk/foo/goo)
should bring us correctly into bdsk:[foo.goo] (/bdsk/foo/goo).
I do not think that this approach is harmful for URLs. URL editors just
assume that they have to share the highest point of relative references -
and they just shall do this.
>
> COPY procedure
> --------------
> It is believed that some operating systems, such as those on
> PCs, includes a file COPY interface, and that this interfaces
> is frequently used. If so, a COPY procedure should be added.
>
NT and W95 file systems do not include this operation.
> Extended Attributes
> -------------------
> A "hidden" and "archive" bit would be useful to PCs using NFS.
Lets call this section Basic Attributes to be distinguished from the Extended Attributes that
you described later. This will be consistent with the terminology of some Operating
Systems (NT, VMS, etc.).
>
> Case Sensitivity
> ----------------
Thank you! This is the second big performance item (after multi-component lookups)!
>
> Opportunistic locking
> ---------------------
> This is an idea borrowed from SMB. Locking can be made
> efficient if the client always tries to lock an entire file,
> even if the application is locking just a part of the file. If
> the client gets the lock, then it can cache the file at will.
> If someone else later wants to lock the file, the server tells
> the first client that it must case "opportunistic locking", and
> lock the file using record locking (after flushing any dirty
> bits in its cache).
>
I understand OpLocks differently. They are not an attempt to enhance
locking by expanding the region. Actually have very little to do with
regular lock at all. They rather have something to do with WRITEs.
They are associated with the byte range (we almost never want to
cache entire file, or even if we do, this is a specific case of the byte range).
OpLocks can be shared or exclusive.
About a week ago I wrote some notes what we (FTP) want to see in the
NFS-4. Following is the section describing shared OpLock behavior.
(I prefer to call them Client Locks - no to be confused with SMB OpLocks).
--- On Tue, 26 Nov 96 14:36:11 PST boris@ftp.com wrote:
7 Client Locks
We need to add the ability for a client to inform a server
that it is caching some ranges of files. This can be done
using a mechanism similar to Blocked Locks. Clients
should be able to issue special 'Client Locks'.
The Client Lock means that the client is caching the file
region specified in this lock. If no user locks are
associated with the region, the requested Client Lock
should be granted. Several different clients can issue
Client Locks for overlapping file regions - these locks
should be granted since they do not conflict. If part of
the region that was requested in the Client Lock request
is already locked via another client's regular
NLM Lock, the Client Lock should be denied. Any attempt
to write into the regions protected by Client Locks, delete
files, or even get a regular NLM lock for any part of the
region should trigger a Client Lock Broken message from the
server to the client. If the Client receives a Client Lock
Broken message, the Client should discard the cache region
specified in the message.
This semantics can be expanded to support not only read
caching, but write caching as well.
One other performance related wish that I included in my notes and could
not find in your proposal is:
7 Wild-carded name parameters for READDIRs
I'd like to expand READDIR(PLUS) syntax to allow
the specification of search targets that can include
wildcard characters. This should significantly reduce the
amount of data we send on READDIRs.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:27 AM Z CST