Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/reports/x3b11.1

Text File | 1991-09-06 | 9KB | 368 lines

.\" Use -mm macros
.\" Care needed--
.\" Andrew uses constant width fonts quite a bit
.\" Replace the CR below by the name of YOUR constant width font
.ds C \&\f(CR
.ds Rh ANSI X3B11.1: WORM File Systems
.ds Au Andrew Hume <[e-mail]>
.ds Dy September 1990
.ds Dt July 17\-19, 1990.
.ds Lo Murray Hill, NJ
.ds Ed Stephen R. Walli <[e-mail]>
.ds Wd U\s-3SENIX\s0 Standards Watchdog Committee
.if '\*(Su'' \{\
.ds Su the \*(Dt meeting in \*(Lo:
.\}
.if n \{\
.tm Subject: Standards Update, \*(Rh
.tm From: \*(Ed
.tm Reply-To: [e-mail]
.tm Organization: \*(Wd
.tm
.\}
.AF "\*(Ed, Report Editor"
.AU "\*(Wd"
.MT 4
.sp
\*(Rh
.if n \{\
.nh
.na
.\}
.sp
.P
\fB\*(Au\fP reports on \*(Su
.P
.sp
.HU "Introduction"
X\s-13B11.1\s0 is working on a standard for file interchange
on random access,
write-once media:
a portable file system for \s-1WORM\s0s.
First let me apologize for tardy snitching
(again);
my excuse this time is that I am now technical editor of the working paper.
I shall describe the results of the last two meetings,
April
(North Falmouth,
\s-1RI\s0)
and July
(Colorado Springs,
\s-1CO\s0),
as a summary of where we are now.
In brief,
the current draft seems fairly stable
and
we expect to conduct
a letter ballot after the next
(October)
meeting.
There is also considerable international activity.
I also discuss our method of electronically distributing our drafts.
.P
.HU "International Activity"
.P
I am still a novice at international standards stuff so take the following with
a larger than normal grain of salt.
.P
The appropriate \s-1ISO\s0 committee,
\s-1SC15\s0,
has been reconstituted
and
had its first
meeting in several years in July in Tokyo.
The meeting was mostly administrative in nature
but
there was a proposal for
a volume structure standard submitted by Fujitsu.
The motivation for this is that Fujitsu intends to introduce
3.5in media
and
drives that can be partially embossed
(like \s-1CD\s0-\s-1ROM\s0)
and partially \s-1WORM\s0
or
rewriteable.
Understandably,
they would like to have a standard volume labelling scheme
to enhance interchange.
They figure that file system layout standards can come along later
but we need the volume labelling scheme Real Soon Now.
.P
A common way for an \s-1ISO\s0 committee to do work is invite some recognized,
accredited
committee to submit a proposal
and
then vote on it.
In particular,
some committee with relatively little administrative procedure.
This means \s-1ECMA\s0,
(European Computer Manufacturers Association,)
and not \s-1ANSI\s0.
.P
Luckily,
the relevant \s-1ECMA\s0 committee,
\s-1TC15\s0,
has just been reconstituted
with its next meeting in Geneva in early September.
Ostensibly,
\s-1TC15\s0's first job is to consider
and
bless the work
of the Frankfurt group,
which has been working on an extension of \s-1ISO\s0 9660
(\s-1CD\s0-\s-1ROM\s0)
to handle \s-1CD\s0-\s-1WO\s0 media.
The very next thing will probably be a volume structure
and
file system
standard,
based on our
(X3B11.1)
work.
(This has required significant changes to our working paper
but
more on that below.)
.P
There is also a dark side to \s-1TC15\s0.
\s-1ECMA\s0 apparently has a hidden agenda for \s-1TC15\s0
that includes the development
of a general storage architecture.
This is the storage equivalent of the \s-1OSI\s0 networking model
with its 7 layers.
The first guess at the layers are:
.DL
.LI
physical layer,
.LI
recording layer,
.LI
formatting layer,
.LI
volume structure layer,
.LI
object management/file system layer
(e.g.
\s-1ISO\s0 9660),
.LI
file structure layer
(e.g.
\s-1ISAM\s0),
.LI
application layer.
.LE
.P
Why does the international activity matter?
(That this question needs to be raised is comment enough for our industry.)
The goal of the standards game is to have a technically sound standard
adopted as soon as possible.
Assume for now that the X3B11.1 draft is technically sound.
How do we get a standard?
One way is to go through \s-1ANSI\s0 procedure,
like the C standard did.
Assuming no problems,
hitches,
objections
and
foulups,
we could have an \s-1ANSI\s0 standard
within two years.
And then we would have to work within the \s-1ECMA/ISO\s0 committees to ensure
that they
adopt a technically equivalent standard
(and thus avoid
the prospect of an \s-1ANSI\s0 standard that conflicts with an
\s-1ISO\s0 standard).
The other way is to work within the \s-1ECMA\s0 committee
and
produce an
\s-1ECMA\s0 standard which then,
given the heavy European presence in \s-1ISO\s0,
would fairly automatically become an \s-1ISO\s0 standard.
Astonishingly enough,
it seems likely that we could
get an \s-1ISO\s0 standard 6\-9 months
.I sooner
than we could get an \s-1ANSI\s0 standard!
(Yes,
sadly,
this means that often the quickest way to get an \s-1ANSI\s0 standard
is to do the \s-1ISO\s0 standard via \s-1ECMA\s0
and
have \s-1ANSI\s0 adopt the \s-1ISO\s0 standard.)
.P
.HU "The Current Draft Working Paper"
.P
In order to facilitate adoption of the working paper by \s-1TC15\s0,
we have made several structural changes to the working paper.
It is now in four parts.
The first part is introductory.
It specifies the scope
and
defines terms.
The second part describes a volume labelling scheme.
It specifies how volumes are labelled,
how partitions are defined,
how volumes are grouped into volume sets
and
a bad sector replacement scheme.
The third part describes a file system layout that is independent of
the details of part two.
The fourth part is a short section detailing the
(very few)
changes needed
to make part three suitable for rewriteable media.
This restructuring was a significant labour,
although it involved negligible
technical change.
.P
.HU "Volume/Partition Structure"
.P
This part is probably the most changed since my last report.
It has become much simplified
and
made independent of the file system specification.
It handles space allocation for the volume,
recording of volume
and
partition descriptors,
definitions of partitions,
and bad-block mapping.
Provision has been made for specifying the type of file system in a partition.
Some of these will be predefined,
such as \s-1ISO\s0 9660
and
9223.
Others
can be registered,
such as proprietary formats like \s-1SGI\s0's \s-1EFS\s0 file system.
.P
.HU "File System"
.P
This has been fairly stable although
many details have been tweaked.
The space management within a partition
and
integrity controls
(essentially the dirty bit for a partition)
have been moved out of
the volume description
and
into the file system description as it was
deemed too complicated to demand everyone support it.
.P
.HU "Technical Editing"
.P
Because of the previous technical editor's health problems,
I was appointed
technical editor.
This has been quite entertaining for me;
I have never been involved in such a complicated document production
(and all of it my own doing!).
A single processing pass produces a table of contents,
an index,
automatically generated data structure layouts,
\s-1ANSI\s0 C declarations of all the data structures,
an \s-1ANSI\s0 C program that tests that the declarations
are correct on your system
(the fields have the correct offsets
and
sizes),
and last
but
not least,
the
.I troff
output.
.P
Each pass runs at least 8 \fIawk\fPs,
4 \fIsort\fPs,
10 \fIsed\fPs,
2 \fIuniq\fPs,
\fIspell\fP,
\fItbl\fP,
\fIeqn\fP,
\fItroff\fP
and
Kernighan
and
Van Wyck's
balancing page makeup backend.
It takes 6 minutes clock time on a 80 mips \s-1SGI\s0 multiprocessor.
(This may not be a game for \s-1PDP\s0-11s anymore
but
at least I know what
to do with all those cycles!)
We iterate until nothing changed since the last pass.
.P
A more noteworthy accomplishment
(than writing more \fIawk\fP
scripts than you can point an editor at)
is that the current draft
of the working paper is available online by both \fIftp\fP
and
email
(\fInetlib\fP).
You can get either of two forms:
PostScript
and
the \fItroff\fP input
(minus all the formatting directives).
This way you can print your standard
and
\fIgrep\fP it too.
The files are \*Cx3b11.1-wp.ps\fP
and
\*Cx3b11.1-wp.text\fP
and
are in the directory
\*Cresearch/memo\fP.
For \fIftp\fP,
login as \fInetlib\fP on \*Cresearch.att.com\fP.
.P
.HU "Finale"
.P
What can,
or should,
you do?
Well,
the worst case is that a standard based closely on the current draft
will become an \s-1ISO\s0 standard for interchange for all random
access disk drives
(optical
and
magnetic).
You not only would have to support it;
you may have to boot off such a disk.
.P
If you wish to comment on the draft,
the best time would probably
be in early November during the letter ballot.
(You of course can't be in the letter ballot because
you aren't a member
but you could give your comments to me.)
.P
If you would like more details on X3B11.1's work,
you should contact either me
(\*[e-mail]\fP,
908-582-6262)
or the committee chair,
Ed Beshore.
I think the two most useful documents
are the current draft of the working paper
(about 60 pages)
and a programmer's guide to the draft
(about 12 pages written by me).
I will send you copies of the latter document;
requests for other documents
or
more general inquiries about X3B11.1's work
would be best sent to Ed Beshore.
.P
The next meeting is in Merrimack,
\s-1NH\s0 on October 21\-25,
1991.
Anyone interested in attending should contact either me
or Ed Beshore
(\*[e-mail]\fP).