SSSWG - July 1997 Minutes
SSSWG - July 1997 Minutes
----------------------------------------------------------------------------
July 1997 Minutes of the
IEEE Storage Systems Standards Working Group (Project 1244)
------------------------------------------------------------
Meeting at River Mountain Lodge
Breckenridge, CO, July 15-17, 1997
Arranged by Rich Wrenn, DEC
Chair: Jack Cole, Model Editor: Sam Coleman
Documents Custodian & MCS Chair: Dixon Hutchinson
Archivist: Bill Wolfe, NASA/Langley Research Center
Attendance (15)
------------------------------------------------------------
Curtis Anderson SGI curtis@sgi.com
Jack Cole ARL cole@arl.mil
Sam Coleman LLNL scoleman@llnl.gov
Brian Dodd EASTMAN brian.dodd@eastmansoftware.com
Mark Epstein SGI mee@engr.sgi.com
Bruce K. Haddon REDCAPE bkh@spot.colorado.edu
Dixon Hutchinson EXABYTE hutch@exabyte.com
Merritt Jones MITRE merritt@mitre.org
Jan Klier HP-SSD jan_klier@hp.com
John Merrill NCAR jhm@ncar.ucar.edu
Geoff Peck SGI geoff@sgi.com
Alan Rollow DEC alan@nabeth.cxo.dec.com
Andy St. Martin DEC stmartin@stmart.cxo.dec.com
Joel Williams SES joel.williams@ses-inc.com
Richard Wrenn DEC wrenn@cookie.enet.dec.com
Administrative.
------------------------------------------------------------
The meeting began at 8:30 am with the usual business of attendance and
registration. Minutes from the Mountain View meeting in March were
approved, as was the agenda for this meeting.
General
------------------------------------------------------------
1. REVIEW OF SAM COLEMAN'S DRAFT REQUIREMENTS FOR MEDIA MANAGER.
After a brief silent reading (or re-reading) of the draft, Sam lead
a review of the draft. Numerous comments were collected, and changes
noted. Sam will produce and distribute a significant revision of
the draft requirements. Rich suggested that the group collect comments
in advance of the next meeting, and limit discussion to acceptance or
rejection of those comments. It was agreed that this approach will be
tried.
2. SGI PRESENTATION OF STATUS OF OPENVAULT.
Curtis presented the current state of OpenVault, collected
comments, and explained SGI's strategies. It is hoped that updated
material can be presented on the SSSWG web site (www.arl.mil/IEEE).
Prior to this meeting, Curtis had stated that changes were made to
the OpenVault engineering effort:
"We decided to change one of the internal technology pieces that we
were building in favor of a much simpler model.
Specifically, we were building the MLM server around a home-grown
relational database and a fairly sophisticated 'compiler'. The
'compiler' took a declarative language (CAPI or AAPI) and turned it
into a procedural language (the interface to the database). By
'declarative' I mean that CAPI doesn't tell you how to arrive at a
result, it just tells you what characteristics the result must have.
By 'procedural' I mean that the database needed to be told what steps
to perform, in what sequence, all in advance.
We are now using a model where the information OpenVault uses to
make its decisions on is stored simply in 'C' struct's and linked lists,
much more as objects that point to each other than as relational
tables. The MATCH clause that was causing us to build a compiler
before is now implemented by an interpreter that looks at the currently
stored data and at the MATCH clause requirements at the same time.
There are zero externally visible changes in the semantics of, or
the interfaces to, OpenVault as a result of this change.
The new path is proving to be very successful."
3. MCS PRESENTATION.
Alan, Geoff, and Dixon lead the discussion of flavors of the MCS
API, and highlights of this written by Alan are appear below.
4. OLD BUSINESS.
No discussion was held on the need to revise and renew all the
SSSWG PARs (except for MCS), since it is recognized that revision will
have to wait for the re-scoping of the MSSRM components and terms.
5. THANKS TO....
Rich Wrenn for arranging a meeting at a very enjoyable location
(even without snow).
Next Meeting.
------------------------------------------------------------
10-12 September Timberline Lodge, OR
PROPOSED Future Meetings.
------------------------------------------------------------
NOVEMBER 11-13, 1997 HOTEL Santa Fe, NM -OR- Florida
JANUARY 13-15, 1998 HOTEL Reno, NV (Geoff Peck) -OR- Long Beach, CA
MARCH 10-12, 1998 HOSTED Boulder, CO (John Merrill/NCAR)
MAY 12-14, 1998 HOSTED Aberdeen Proving Ground, MD (Jack Cole/ARL)
JULY 14-16, 1998 HOSTED Redmond, WA (Jonathon Otis/ADIC)
ATTACHMENT
------------------------------------------------------------
MCS DISCUSSION - by Alan Rollow
o Geoff made a quick pass through his version of routines
which came to rest in a discussion of whether to do
modal asynchronous I/O or something else. While it
was recognized that nobody actually supports command
queueing in media changers, it was also recognized that
that wasn't sufficient reason to carve the interface
into serial stone. The overall opinion I remember was
that the interface should try to pretend to be asynchronous
and those wanting serial command can drop in calls to
mcs_lib_async to force waits.
There was also considerable off topic discussion as people
came to agreement on what their words for particular things
really meant.
o The next major topic after this was on how to make the
interface extensible for those uncommon, but value added
features that vendors insist upon putting into devices.
This turned into a discussion more on how such a thing
could be implemented on various systems. It appeared to
have the draw-back that it required robot vendors provide
a software component that MCS could use to provide the
desired functions.
o Finally, I made the mistake (though quite planned) of
asking who the intended consumer of MCS was. If the
consumer is a person writing an LCP for MMS, then the
method of getting to value added features doesn't
necessarily have to be easy. It may even be that the
LCP writer will not use MCS at all, suggesting that
LCPs are the consumers of MCS.
This leaves the users of the world that don't or won't
use MMS but need media changer control. When this is
is the intended audience, MCS can be somewhat simplier
than it is (such as it is) at the moment.
If an MMS is sufficently low cost, easy to install and
use, then there may be no need for MCS at all.
The conclusion seemed to be to review the charter for MCS.
These aren't particularly good as minutes and I know I missing
a lot of possibly useful information from the discussion of
what words meant. At one point Rich and I both pointed out
our personal experience that it is hard to keep logical changer
state and physical state consistent, which has implications
for doing lots of caching in MCS.
SSSWG Home