jsh@usenix.org (Jeffrey S. Haemer) (12/03/89)
From: Jeffrey S. Haemer <jsh@usenix.org>
An Update on UNIX* and C Standards Activities
December 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.8/1: POSIX Transparent File Access Update
An anonymous correspondent reports on the July 10-14, 1989 meeting, in
San Jose, California:
[Editor's note -- Though this report came in substantially later than
the other July reports, I think it's still useful, provocative, and
well worth reading. -jsh]
Overview of New 1003.8 Developments
1. All standards produced by POSIX committees (with the exception
of language-binding standards like 1003.5 and 1003.9) must be
specified in a language-independent fashion, and must include at
least one language-specific binding. Since P1003 will not have
guidelines and rules for constructing a language-independent
specification before April 1990, no POSIX networking group can
possibly ballot a document before July 1990. "Mock" ballots
(aka trial-use ballots) are unaffected by this, but their
usefulness will be diminished.
2. Two new POSIX Networking working groups either have submitted or
will soon submit PARs to begin work, bringing the total number
of POSIX Networking working groups to six. These new groups are
the Name Space and Directory Services Interface and the X.400
Mail Gateway Interface. [Editor's note -- The SEC approved the
PAR for the former, but decided that the latter transcends
POSIX, and recommended that the IEEE form a separate, numbered
group, analogous to 1003 or 1201, to handle X.400. See below.
-jsh]
3. Due to the rules governing IEEE and IEEE-TCOS standards
activities, as well as the logistical nightmare six sub-working
groups cause, the hierarchical structure of the P1003.8 POSIX
networking committee will be flattened out, with each current
sub-group submitting PARs to cover their current work.
Coordination will be provided by a "POSIX Networking Steering
Committee", made up of the chairs and vice-chairs of each
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access
- 2 -
networking-related working group and the current chair and
vice-chair of 1003.8. [Editor's note -- This is still being
debated by the SEC. -jsh]
4. Since each of the 1003.8 sub-groups will be submitting separate
PARs, the P1003 Sponsor's Executive Committee (SEC) is taking
the opportunity to evaluate the degree to which each PAR is
intended to represent a part of the "POSIX Environment" or is a
component which has no relationship to the rest of POSIX and
should, hence, stand alone. The result of this is that several
of the 1003.8 sub-groups may be issued project numbers outside
of the P1003 family. There is some precedent for this; the X11
interface group was assigned project number P1201 for just this
reason.
Activity in the TFA Subgroup, P1003.8/1
The group is making slow but steady progress towards the goals of a
fully-specified programmatic interface for networked file access and
the semantics and suggested syntax for administrative interfaces for
such a functionality. The group is dominated by a faction, apparently
lead by Sun Microsystems, with a goal of ensuring that NFS, in some
form, is a sufficient mechanism to provide the service required by the
"full TFA" interface. The balance of the committee is composed of
people who simply want a standard they can use as an acquisition tool.
Achievements
+ Enough consensus and material was obtained to permit development
of a first draft of the programmatic interface part of the
specification; this draft should be complete in time for the
second mailing, due out on September 8.
+ Liaison activities with 1003.7 (System Administration) continued;
.7 indicated that all of the options for the TFA mount/unmount
model were, in fact, of use in administering such a system. They
also agreed that they owned responsibility for all file-system
commands not completely unique in function to TFA, and that they
would pursue input from the TFA group when the time was right.
+ Further progress was made on identifying status and usage
information which must be obtainable from the provider of a TFA
service.
December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access
- 3 -
Problem Areas
1. Representation in the group is unbalanced; there is, as of this
time [Editor's note -- July, '89 -jsh], no substantial
representation of the "stateful" side of the semantic issues.
The chairman has, so far, been unsuccessful in encouraging a
more balanced group viewpoint so representation from the
stateful camp has been solicited (with minimal success) for
future meetings.
2. Several "grey areas" in the semantics of IEEE 1003.1-1988 have
been identified by the TFA group over the last several months.
The suggested "fixes" have been slanted in a way that would let
the TFA interface avoid relaxing 1003.1 semantics while
permitting a stateless implementation of the TFA service; i.e.
rather than strengthening 1003.1 to define the actual behavior
of a single stand-alone system, the proposals have been so weak
that they underconstrain single-system behavior. It appears
that the majority of the 1003.1 committee will not approve of
this approach, and will require the "fix" to be of the proper
strength to correctly specify single-system behavior.
Let me give an example. The original 1003.1 standard is silent
on the issue of when the effects of a write are visible to a
subsequent read of the same byte of the file. If process A
writes byte 123 of file "foo", then process B does a read of
byte 123 of file "foo", at what point is B guaranteed to see the
byte A wrote?
Immediately? If so, stateless solutions employing read caches
fail; if process B is remote on system "bsys" and reading the
file via NFS, byte 123 might come out of the file cache on bsys
and not from the file cache on the system where A lives.
Immediately if A and B are on the same system, and at some
implementation-defined time otherwise? This requires 1003.1 to
define what it means by "the same system", and doesn't
adequately address multi-processor single systems with
"interesting" caches. It also means a truly portable
application that is interested in running in a distributed
environment can *never* know when the byte written by A is
visible to B.
Only in the presence of byte locking? In other words, A locks
byte 123, writes it, unlocks it; if B then locks and reads 123,
it is guaranteed to see what A wrote. Not a bad solution, but
it breaks existing applications and in fact is a relaxation of
the intended semantics of 1003.1.
Basically, the "intent" developing in 1003.1 is that the effect
of the write must be seen immediately by any other process with
December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access
- 4 -
that file open, without regard to process location, without
recourse to O_SYNC mode opens, without the necessity for
locking, and so on. 1003.1-1988 is silent on the issue; the
proposed fix from TFA (basically a compromise I did not like and
knew would fail) was that read-after-write be guaranteed only
for co-located processes and in the presence of locking. This
gave 1003.1 a chance to avoid relaxing their intended semantics
while leaving TFA a "loophole" to change semantics without
having to indicate a change in wording from 1003.1.
This is what got rejected by 1003.1, which is getting pretty
damned tired of TFA's trying to claim that the full TFA
semantics are "just like" 1003.1 but with gaping differences
that are introduced silently due to weak or weasel wording in
1003.1-1988.
3. 1003.7, System Administration, is making distressingly slow
progress. If this continues, 1003.8 will have two choices with
respect to client-side administrative commands:
- Do not standardize them; give feedback to 1003.7 and wait
for them to complete their specification. This risks
incompatible implementations.
- Standardize them insofar as they relate to TFA
administration. This risks incompatibility between the TFA
aspects of those commands and their more general aspects.
An example is the "mount" command; if 1003.7 is unhappy
with the form of the TFA mount command, they are under no
constraint to remain compatible with it. If the group
ballots far enough in advance of 1003.7, this sort of clash
could be frequent.
4. Many of the contentious issues have been "resolved" through the
various mechanisms POSIX provides for introducing optional
behavior; most frequently, these involve either
"implementation-defined" behavior, or the addition of path-
specific attributes whose status can be determined through the
pathconf() function. Several of these options should be viewed
by the ballot group as being "gratuitous" in some sense, i.e.
the TFA committee should take a stand one way or another, and be
willing to be beaten up in ballot for it. The POSIX standards
are wishy-washy enough without the addition of gratuitous
options.
December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access
Volume-Number: Volume 17, Number 80