From: boris@ftp.com
Date: 12/08/96-06:33:24 AM Z
From: boris@ftp.com
Date: Sun, 8 Dec 96 04:33:24 PST
Subject: RE: Kick-off discussion
Message-Id: <B-Mailer->961208043349.boris@ntbook>
Hello,
--- On Sat, 7 Dec 1996 05:40:10 -0800 (PST) Mike Eisler <mre@pacific.Eng.Sun.COM> wrote:
>boris@ftp.com wrote:
>
>> --- 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.
>
>What file handle do you use with this READDIR?
A special server's VIRTUAL file handle.
> Consider the case of
>an NFS server that exports dis-joint portions of its namespace:
>
> /export/home16
>
> /pub
>
>If one just does a LOOKUP START_FROM_ROOT "/" from the client, my V4 server
>is going to refuse the access, because / isn't exported. And even if it
>did return a file handle, it won't permit a READDIR of "/" because "/"
>is unexported. There might be a directory under "/" whose name I want
>to keep confidential ... say "/the_boris_files" :-)
"/" is totally UNIX-ish notation of the absolute root for a file system.
Probably I have not completely understood you when I read about your
'virtual' root. Let me explain how I'd like to see it. Doing this I'll
intentionally use VMS file notations that is as foreign for us
(NT and W95 shops) as it is for you (UNIX people).
Let's say VMS NFS server exported two directories:
adsk:[dir1.dir2]
bdsk:[foo.goo]
I'd like to be able to issue a READDIR to the special server's
VIRTUAL file handle representing a top level VIRTUAL directory
on the server and get back the list of the exported files only
'adsk:[dir1.dir2]', 'bdsk:[foo.goo]'
with their file handles and their attributes (for READDIRPLUS).
The READDIRPLUS can additionally return some Extended Attributes
(well defined in the protocol), describing special export-related
properties. Clients should NOT make ANY assumptions about the
semantics of the returned file names of these exports, but rather
should treat them as single component names.
An attempt to do READDIR for 'bdsk:[foo.goo]'\.. will NOT
bring a client to 'bdsk:[foo]', but rather brings to the level
of the VIRTUAL directory.
SMB takes the idea that names of shares cannot be analyzed
even further. It actually assigns a simple single-component names
to shared directories. Thus it solves the security problem
similar to one that you identified above: when we export a sub-tree
"/Mike/the_boris_files" we may want to keep the real
name of this sub-tree on a host computer confidential.
The next release of our NFS server will give users an option to
associate a simple name with an exported point.
>
>>
>> > 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.
>
>I'm open to suggestions. It would also be great to have a model that
>doesn't introduce extra administration over and above the security
>mechanism being used in the RPC header.
Agree.
But we should somehow break this knot when a file ownership
Identity is described in UNIX terms of uid/gid because of RPC UNIX
authentication and we use RPC UNIX authentication because it so
conveniently matches the file ownership Identity model.
>
>> >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.
>
>A client that doesn't grok fileid doesn't have to use it right?
I believe that file should be uniquely identifiable by one item
only, the file handle. Redundancy is usually a source of a problem.
Our server struggles to generate this field. At least let us put
a 0 there, please.
>> 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
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>This doesn't parse. Are these overlapping locks READ locks?
Yes, here I was speaking only about the read cache support.
>
>> 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.
>
>Does the 2nd client that does the write have to block while the server
>is delivering the Client Lock Broken message to 1st client?
No, it does not.
>How is this different from a full blown cache coherency (with all the
>recovery problems)?
This only supports the read cache. It covers about 70%-80%
of what we want to cache. It does not have a problem that we see
with the write cache when write cache buffers have to be flushed before
completing the competing reads. In this simplified model we just
have to inform clients that read cache buffers have to be discarded.
Sorry, I fail to see how the recovery of such Client Locks is
different from the recovery of the regular NLM locks.
-----------------End of Original Message-----------------
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:28 AM Z CST