NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/std/unix/417

Internet Message Format | 1992-09-09 | 8.5 KB

Path: sparky!uunet!uunet!not-for-mail
From: [e-mail] (Peter Collinson)
Newsgroups: comp.std.unix
Subject: Standards Update, ANSI X3B11.1: WORM File Systems
Date: 9 Sep 1992 14:38:13 -0700
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Lines: 174
Sender: [e-mail]
Approved: [e-mail] (Moderator, Sean Eric Fagan)
Message-ID: <[e-mail]>
NNTP-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen Walli <[e-mail]>, Report Editor
Report on ANSI X3B11.1: WORM File Systems


Andrew Hume <[e-mail]> reports on the May 11-15, 1992
meeting in Pasadena, CA: and on the TC15 meeting on June 22-25, 1992
in Reading, England.

Introduction

X3B11.1 is working on a standard for file interchange on random access
optical media: a portable file system for WORMs or rewritable optical
disks.  TC15 is a committee within ECMA that works on file system
standards.  This report covers the last three X3B11.1 meetings in Santa
Clara, California, Denver, Colorado and Pasadena, California and two
recent TC15 meetings in Denver, Colorado and Reading, England.  In
brief, we have an ECMA standard!

Pardon my laggardly snitching; I have been snowed under this year.  In
trying to meet the deadline for the June ECMA General Assembly
meeting, I have attended 5 standards meetings in the first six months
of 1992 (all but one was a full week) and I redacted new drafts for
every one.

ECMA-167

Editorially, ECMA-167 is arranged as five separate parts.
Semantically, these form four independent standards.  (Part 1 contains
general references and definitions.)

   - Parts 1 and 2 describe a general scheme for recognising standards
     used to record the medium (is it ISO 9660, ECMA-167, or perhaps
     both?) and for recording boot blocks.

   - Parts 1 and 3 describe a volume structure standard, which
     includes support for volume labels, volume sets, volume
     partitions and logical volumes (which may span multiple physical
     volumes).

   - Parts 1 and 4 describe how to record hierarchical file systems
     (assuming we have a suitable underlying volume structure
     scheme).  The file system is approximately a POSIX (ISO 9945-1)
     file system augmented by extended attributes.

   - Parts 1 and 5 document the arcarna of record-structured files.
     ECMA-167 has to support record-structured files, if only for
     backward compatibility with ISO 9660, and making it a distinct
     part allows other standards to easily use the same specification.

An important aspect of each of these parts is their interfaces.  The
input interface describes what the part needs in order to work.  The
output interface describes what the part allows you to specify (and
perhaps use as input to another part).  As an example, Part 5 (record
structure) has a single input, the data space of a file, and two
outputs, the identification of record formats and record display
attributes.

International Activity

There is a lot of international interest in volume and file structure
standards, particularly for removeable optical media.  That is why our
committee has an ISO standard as its main goal, rather than an ANSI
standard.  That is also why we have bent over backwards to solicit
input from, and work with, Europe (ECMA), Japan (JNC), and ISO (SC15).

We reached our first major milestone on June 25 when the ECMA General
Assembly accepted our draft as ECMA-167 by a vote of 30 yes, 0 no, and
1 abstention.  Regrettably, the General Assembly chose not to forward
the standard for fast-track processing within ISO at this time; it will
probably do so at its December meeting.

With the exception of France, we do not expect any problems when ISO
SC15 processes ECMA-167 as a DIS.  France's objections draw mainly
from a French company's claim that adopting the standard will have
dreadful performance impact on that company's products.  We have
discussions ongoing about this and other issues but our basic response
is twofold:

   o our standard is an interchange standard.  There is no intent that
     integrated applications adopt our format for their internal data
     format.  They might, however, adopt our format for the import and
     export of data.  As a concrete example, we do not anticipate that
     Epoch's Infinite file server product will change to use our
     format for their disk format (although they could).  However,
     Epoch might interchange files into and from their server in our
     format.

   o while we have spent considerable effort to minimise the number of
     seek's to access files and their data, the bottom line is that
     for good performance, you will have to have some kind of cached
     database that maps file or directory names to disk addresses.
     Optical media, particularly 12in media, is just too big and too
     slow (although a cache helps relatively fast magnetic disks as
     well).  We decided that a portable high-performance cache was a
     contradiction in terms and too hard to specify in any case, and
     so we left it to each implementation to decide what, and how, to
     cache.

Future Activity

The work in ECMA and TC15 has one single focus, getting the standard
into the ISO fast track process.  From here on in, the process is
purely political.  Other than acting as a technical resource, I am
pretty much a bystander now.

The process in X3B11.1 is, unfortunately, just as political.  Because
X3B11.1 is a sub-committee, our parent committee, X3B11 has to approve
most of our official activities, and in particular, drafts for
processing as ANSI standards and positions for the US TAG to SC15.
Ordinarily, this is not a problem but recently, a couple of members of
X3B11 starting throwing as many roadblocks in our way as possible.  As
ANSI has more procedures than probably any other standards
organisation in the world, this could mean considerable delay in ANSI
processing.  As a result of all this hooey, X3B11.1 is changing its
focus from technical issues to politics and has now scheduled its
meetings concurrently with X3B11 so we can at least argue our own case
and cut down on the amount of misrepresentations and falsehoods being
made about our committee and its work.  (I gave a well-received
presentation on our work at the August X3B11 meeting and was present
during discussions of X3B11.1's work; this was a real win.)

Just remember, the technical content of a standard is very important,
but getting a draft through the standards process is just as important.

Electronic Distribution of Standards/Drafts

Since I became technical editor of X3B11.1, my drafts have been
available electronically by both ftp and email (netlib) from
research.att.com.  (For ftp, login as netlib.) For details, get index
from research/memo.

As far as our standard is concerned, there are three
documents:

   - the standard itself (121 pages including TOC and index).  (Of
     course, it can't be the actual standard as ECMA owns the
     copyright on that but rather, the final draft of TC15; ECMA takes
     this draft and reformats it using a word-processor program and
     then publishes it.)

   - a technical overview (12 pages).  This gives a high level
     overview but has significant technical content.

   - a programmer's guide (20 pages).  A low level guide through the
     standard from a C programmer's point of view.  It gives you
     enough details to do design an implementation and do most of the
     implementation.

Finale

Finally, we have a standard and can now complete our implementations.
Although there is considerable procedural work to do, the hard stuff
is finished.  The technical work has been quite interesting, as has
been the role of technical editor.  (Mind you, I am scarred for life;
I can read standards quite easily now and find myself tsk'ing at
poorly written ones.) Writing a precise description of a nontrivial
system is obviously hard, but you never appreciate how hard it is
until you do it and then have a whole bunch of folks ballot on it.

If you wish to comment on the standard, get a copy electronically, or
contact me or the X3B11.1 chair (Ed Beshore) for a copy.  I will make
sure any comments sent to me go to the right folks.

If you would like more details on X3B11.1's work, you should contact
either me ([e-mail], 908-582-6262) or the committee
chair, Ed Beshore ([e-mail], 303-350-4826).

The next meeting is in Orange, CA on August 12-14.  Anyone interested
in attending should contact Ed Beshore.

Volume-Number: Volume 29, Number 29