(was slashes, now NFS devices)

[Mike Eisler]

In article <1991Mar3.225844.8814 at panix.uucp> zink at panix.uucp (David Zink) writes:
dz>So lm at slovax.Eng.Sun.COM (Larry McVoy) babbles:
lm>>I think that you've missed the point.  Special files are merely entry points
lm>>into devices.  It is much more likely that the file makes sense to the client
lm>>than the server.  It has nothing to do with DOS.
dz>
dz>No, McVoy, YOU'VE missed the point. The DOS machine should not be told
dz>"Here is a major and minor number, now interpret them locally." Major and minor
dz>numbers CAN ONLY MAKE SENSE to the machine that creates them.

Diskless clients create device nodes.  So major and minor numbers DO
make sense to the machine that creates them.  Indeed, the entire root
partition that the devices typically live on only makes sense to the
diskless client that (exclusively) mounts it.  And how do you feel
about program executables? Should a CRAY UNICOS executable be
executable on a PC if accessed over NFS?

I'm not saying the diskless clients are the only clients NFS should
support nor am I saying that there isn't a place for transparent device
sharing, and transparent remote execution, but don't blame NFS for not
doing something it never pretended to do. If people want these things
made transparently available, then they certainly could be, but in the
context of another (stateful) protocol that the NFS client redirects in
a manner similar to the lock manager (but hopefully designed a lot
better). RFS and company on the other hand, pretended to be
heterogeneous, yet don't interoperate any better than NFS does when the
machine types are different, even when running the same version of
UNIX.

lm>>>And to Unix users, NFS is not stateless. What is rpc.lockd used for?
lm>>Whew!  Where did this come from?  NFS is stateless.  The locking gunk is

dz>This came from NFS, bozo.

lm>>and has been a problematic aspect for some time.  Sorry.  That's one of

dz>A problematic aspect of NFS.

If you want to talk about how badly KLM was implemented, or attack the
KLM protocol fine. That's a separate issue, because the KLM protocol is
separate from the NFS protocol. The KLM and NFS protocols are
integrated into the NFS file system. Any file system is free to use
KLM. In fact when Sun first produced it, both the local and NFS file
systems used it. Certainly RFS could use KLM if it wanted to.

lm>>the main reasons that the locking is a wart on the side.  It's hard to
lm>>get right.

dz>Given that you do everything alse wrong.

There are degrees of wrongness. I'll take Sun's wrong over AT&T's until
AT&T shows they have something that crosses architectures, and doesn't
kill my clients' processes when the server crashes. At least the guys who
designed NFS opted to not go for the

	Great-American-Proprietary-Operating-System-Feature

that would have locked all the vendors into supporting SunOS features
(had they been stupid enough to fall for it).  The NFS designers
decided on a subset of things that let all operating systems
hetereogenously share data.  And given the success of annual
demonstrations like Connectathon, and Uniforum's show net, one can
conclude their decisions may not have been perfect, but they were
pretty good.

>And if NFS is 'good' because its 'successful' I suppose you'll insist that
>MS-DOS is better than Sun-OS?

NFS became successful because vendors of computer equipment, big and
small analyzed the technology and decided that it would be a good thing.
Having Sun behind it had little influence; they weren't exactly a
household word then. DOS became successful because a large part of the
country got a hard on over a box with IBM's initials on it. They could
have cared less if in ran DOS, CP/M, UNIX, or MVS/OS.
	
	-Mike Eisler
	mre at pyramid.com