Extended file system on UNIX 4.2/4.3 BSD

[Barry Shein]

Chuq hesitated to overview the SUN NFS for fear of being accused
of commercialism. I for one would love to hear an overview of the
system tailored for the level of this group, from someone who knows,
and that's likely to be someone within SUN.

Given the fact that SUN has bent over backwards to get other vendors
to adopt the protocol (making specs and code available) it borders
on silly to feel that this is very commercial (it would be like
discouraging AT&T folks from talking about UNIX.) [Oh, and many
vendors seem to be real serious about implementing it very soon.]

There was an article overviewing it (and contrasting it to Apollo/Domain
and, especially, ATT/RFS) in this past UNIX/WORLD 'zine, but as is
typical of these articles it was written for the masses and had few
technical details. Besides, bet a dollar the people who know from
both groups thought it was a bit misguided often (written by Apollo
folks tho the intent was sincere.)

I currently have a cluster of 4 diskless and one server SUN and from
the user level it is quite transparent (the other file system(s) graft
into the tree.) I am aware of the non-transparencies in some of the
semantics (locking, multiple update) but I think none of these are
fatal for now and there are benefits caused by the design (if the server
goes down the diskless node in my office just pauses, informs me and
when the server comes back continues without a hitch.)

I would love to hear about ATT's RFS also (we have a 3B5 and 3B2s and
if it is made available they are perfect candidates for this I believe.)

I have often thought that a good use of this list is to publish highly
technical, brief overviews of new developments as well as bugs etc.

Perhaps the protocol to prevent net overdrive is to have people offer
to overview with a very short request (unlike this soliliquoy) and see
if the interest (and/or objections) is/are there.

Anticipating the suggestion that something like net.unix be used I would
suggest that the reason to use this list is to try to keep it to a very
high technical level (things like administration, operations, kernel
changes, design issues etc) rather than 'here kiddies' stuff.

Agreed? Another possibility is to form a separate list but I see little
benefit from that, I doubt we will be swamped with such things.

	-Barry Shein, Boston University