home *** CD-ROM | disk | FTP | other *** search
- .\" 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 <andrew@research.att.com>
- .ds Dy September 1990
- .ds Dt July 17\-19, 1990.
- .ds Lo Murray Hill, NJ
- .ds Ed Stephen R. Walli <stephe@usenix.org>
- .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: std-unix@uunet.uu.net
- .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
- (\*Candrew@research.att.com\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
- (\*Cedb@hpgrla.hp.com\fP).
-