NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/protocol/nfs/2329

Internet Message Format | 1992-09-14 | 5.4 KB

Path: sparky!uunet!sun-barr!news2me.ebay.sun.com!exodus.Eng.Sun.COM!pepper.Eng.Sun.COM!cmcmanis
From: [e-mail] (Chuck McManis)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS Protocol Specification
Date: 15 Sep 1992 09:14:00 GMT
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 106
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: pepper

(Mike van der Velden) writes:
>... comments, except for two issues on which people are about evenly
>divided:
>
>a>  Should the server be stateful or stateless?
>b>  Should the protocol provide a mechanism for locking files (or
>    parts of files)?

You may have realized by now that these are the same question.
"Locking" implies state (the locks) so a protocol that has a
notion of locking is stateful with respect to who is accessing
what.

If it were simple it wouldn't be fun :-)

You can think of distributed file systems as this multiaxis
design space where moving toward optimum along one axis drags
you away on another. Lets use the "state" axis as an example.
In a "stateless" protocol you get excellent recovery properties,
the server can crash and reboot and with no additional overhead
continue serving clients even in the middle of a read. With a
completely "stateful" protocol when the server crashes is forces
all clients to immediately abort. Stateless protocols have poor
data sharing properties because that implies an arbitrator for
access between two clients that doesn't exist (the server has no
"state" associated with who is accessing what) whereas a stateful
server can enforce exclusive locking and atomic updates.

For different situations and designs, sometimes one is better than
the other, sometimes not. Other factors come into play as well such
as how reliable is your network? The machine that is executing the
server code? How much bandwidth do you have to spend on such things
as "update" messages? Whats the latency between a request and a
response ? All need to be considered when designing the protocol.

>Here is a brief synopsis on some other points raised:
>   - data size should be > 8K.

Stated differently this implies more efficient use of high
bandwidth networks. For a 56K ISDN connection a packet > 8K
causes bursty behaviour as the large packets swamp the communication
channel for relatively large amounts of time.

>   - a connection based transport is more desirable than UDP.

This is half of the state issue. You see NFS is a protocol layered
upon another protocol (RPC/XDR) which is itself layered upon another
protocol UDP/IP which is layered upon the ethernet (CD/CSMA) protocol.
What TCP (or any other connection based protocol) does for you is
create state (a connection) between you and your server that helps
you do things like recognize right away that a server has gone down.
Other non-connection protocols like VMTP can give you similar benefits
with a somewhat easier recovery mechanism.

>   - clients should cache files, or parts of files.

Helps you move along the read performance axis, pulls you back from
the "easily write shared" axis. If you cache a file and write on it
after all you need to make sure no one else has (or will) write on
the same place. More protocol, more state, tougher recovery from
errors, and less performance on writes.

>   - Unix file view should be extended, perhaps incorporating space
>     for uninterpreted meta-data.

Another axis you can choose to go up or down. The more you assume
you are talking to UNIX boxes only, the more assumptions you can
make and simplify the protocol (existence proof == AT&T RFS). Of
course if you want a truely heterogenous protocol that talks to
all systems that have a notion of file storage then you probably
want to design some extensible way of representing arbitrary
attributes associated with a chunk of data that is the "file".

>   - security should be improved.

This ones got three axises (axii?) Authentication, who do you
give access to and how do you verify they are who they say they
are, authorization which ties into the one above and for UNIX
is pretty straight forward, for VMS it is more tricky, and finally
privacy which would be preventing people from snooping files by
capturing packets. Government types on labels and mandatory access
controls etc. Again you have to find a spot that is comfortable to
you, probably something that is more difficult than breaking root
on a machine but gives finer grained access than Secure NFS does.


>Again, any other opinions you might have on these or other issues are
>welcome.  Thanks in advance for your time.

You're welcome after the fact :-)

Getting a single protocol that a wide audience can agree on is a real
challenge, deciding what to optimize for takes clairvoyance. You might
start out by building a distributed file system "toolkit" where you
can bang together arbitrary protocols to test various configurations.

The "synthesis" kernel stuff that generated device driver code when
you opened a device looked interesting in this regard. That is being
able to set any of these axis points on a file by file basis might
prove to be a useful protocol.

--
--Chuck McManis                            Sun Microsystems
uucp: {anywhere}!sun!cmcmanis   BIX: <none>   Internet: [e-mail]
NIS+ Architect
These opinions are my own and no one elses, but you knew that didn't you.