SSSWG - January 1997 Minutes
January 1997 Minutes of the
IEEE Storage Systems Standards Working Group (Project 1244)
------------------------------------------------------------
Meeting at Veritas Software Corporation
Mountain View, California, January 21-23, 1997
Hosted by Anat Gafni and Carl Braganza
Chair: Jack Cole, Model Editor: Sam Coleman
Documents Custodian & MCS Chair: Dixon Hutchinson
Archivist: Bill Wolfe, NASA/Langley Research Center
Attendance.
------------------------------------------------------------
Curtis Anderson SGI curtis@sgi.com
Carl Braganza VERITAS carl@veritas.com
Loellyn Cassell SGI cassell@sgi.com
David Cohrs LEGATO cohrs@legato.com
Jack Cole ARL cole@arl.mil
Sam Coleman LLNL scoleman@llnl.gov
Jim Daveler LLNL daveler@llnl.gov
Mark Epstein SGI mee@engr.sgi.com
Ed Gasiorowski IBM edward_gasiorowski@vnet.ibm.com
Anat Gafni VERITAS gafni@veritas.com
Mike Hardy SGI mhardy@engr.sgi.com
Dixon Hutchinson EXABYTE hutch@exabyte.com
Mike Johnson TRACER TECH. mpj@tracertech.com
Merritt Jones MITRE merritt@mitre.org
Paul Lockwood LEGATO plock@legato.com
Jonathan Otis ADIC jonathano@adic.com
Geoff Peck SGI geoff@sgi.com
Steven Solbeck LLNL ssolbeck@llnl.gov
Eric Stouffer IBM stouffer@vnet.ibm.com
Joel Williams SES joel.williams@ses-inc.com
Rich 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 Cupertino meeting in November were read
and approved, as was the modified agenda for this meeting.
Recap of the November Meeting.
------------------------------------------------------------
At the last meeting (November, Cupertino) SGI presented version 1 of
OpenVault, and attendees made many comments in review. SGI proposed
working with the SSSWG toward an open standard which merges the SSSWG
and SGI efforts. Many in the SSSWG expressed interest in working with
SGI in such a merger of ideas, particularly because of availability of
OpenVault to the public at nominal fees. We left that meeting with the
desire to hear more about OpenVault, specifically in a modeler's
perspective.
This Meeting.
------------------------------------------------------------
We scheduled the first day to listen to the modeler's perspective of
SGI's OpenVault, but this turned out to be more of a review than a
one-sided presentation because of the questions posed by attendees. As a
consequence the 'presentation'/review extended into a second day.
Copies of slides used by SGI in their presentation and OpenVault design
specifications were distributed to attendees. OpenVault web pages
distributed before the meeting are shown here.
Tuesday attendees enjoyed an evening out at Stars, an excellent Palo
Alto restaurant.
Wednesday was devoted to work on MCS (notes follow) until late morning
when Mark Epstein presented the OpenVault database model. After a late
lunch, the meeting resumed with discussion of the direction SSSWG is
taking or may take in blending MSSRM and OpenVault designs. This
discussion continued Thursday until adjournment at 12:40 pm.
From the November meeting and this meeting it is clear that OpenVault is
evolving rapidly with significant benefit from the SSSWG comments and
reviews. While these meetings have been spent understanding the design
of OpenVault, the SSSWG has not had time to determine how the MSSRM or
APIs should or might be modified. Further OpenVault issues were
identified for greater examination and development:
1. security/authentication
2. labels, etc
3. "global name space" - interapplication media sharing
4. data mover issues
5. resource locking, reservations
6. notion of time
7. principal vs application (resource ownership)
Closing discussions developed some statements of goals for the March
meeting and elicited some concerns about OpenVault. The following is a
sampling of these, and not a complete listing.
Joel believes that the best place for the SSSWG to start to assimilate
the ideas from SGI is in standardization of the semantics of OpenVault
(verb use, database contents, etc). And he intends to complete an
initial effort in this direction before the March meeting.
Dixon will continue to develop MCS with other participants, and part of
the March meeting will again be devoted to MCS as a subgroup of SSSWG.
Many at the meeting expressed the need to restart work on MOVER, both
for the MSSRM and for OpenVault. Tom Weimer/Veritas ,
who sat in for Carl and Anat Thursday morning, said that he will try to
present Veritas' MOVER model at the March meeting.
Sam wants to see the terminology of OpenVault reconciled with the MSSRM.
And Anat expressed the need for completeness and accuracy in OpenVault,
which is at present much less mature than other storage system software.
Many expressed the desire to balance greater progress by the group
with continued accommodation of competing ideas among friends.
MCS Discussion (notes by Dixon)
------------------------------------------------------------
The bulk of the discussion centered on what we are trying to address
with this API.
1) There is a need for a device driver standard interface. This is
outside the scope of the MCS PAR since the PAR specifically mentions
"operating system independent". An effort for a standard device driver,
for example, a common set of ioctl's, probably belongs under the control
of POSIX.
2) There is a need for the SCSI Medium Changer (X3T10, project 999D) to
be expanded to include the functionality that is commonly available but
is vendor unique (e.g LCD panels).
3) There was consensus on the following with respect to the MCS API.
The library that implements the API should:
a) Provide operating systems independent interface
b) Provide functionality approximating SCSI functionality
c) Provide an escape mechanism for vendor unique functionality.
d) Hide the device-dependent differences in the core MCS functions:
Move, Inventory, Inquiry...
e) Provide standard API to "common" vendor unique features: LCD
panels, ....
f) Hide device dependent differences in Input/Output Doors
(this was not quite a consensus)
g) Allow that each operation provided by the API have minimal side
effects
h) Use common methods for reporting error status
i) Provide simultaneous access to multiple dissimilar robots.
j) Not require persistent data....Hmmm hard to say in ten words....
The goal is not to avoid persistent data within the library. In fact,
most tape library products do store persistent data. The goal is that
the API should not require persistent data. That is, before running
an application that uses the API, one should not have to edit a set of
configuration files. The reason for this is that the application may
be one which is there to help you determine configuration data. So,
the configuration data should be held in higher-level applications or
it should be optional behavior of the API, but it should not be required
for the API to function.
Next Meeting.
------------------------------------------------------------
March 25-27 at the Boulder Courtyard, Boulder, Colorado
Future Meetings.
------------------------------------------------------------
Tentative Schedule of Future Meetings:
13-15 May Key West, FL/Jack
15-17 July Colorado/Dixon
16-18 September Portland, OR (Timberline Lodge)/Jack
November San Diego?
SSSWG Home