diglib: Revised meeting minutes

[Robert Felsing <felsing@OREGON.UOREGON.EDU>]

Digital Library Group Meeting 
2/14/01 

Attendance : Bob Felsing; James Fox; Will Harmon; Nancy Slight-Gibney;
Normandy Helmer; Carol Hixson; JQ Johnson; Travis Ritter; Mark Watson;
Colleen Bell

Mark convened the meeting with note of the fact that Sara Brownmiller will
be mounting, on Libweb, a "digitalography" of messages, citations, source
materials, products, etc. that are generated by Diglib in the course of its
discovery and deliberation.

Tom Stave was not prepared to talk on the Government Documents/MAPS projects
and did not attend the meeting.

Mark raised the issue of agenda setting for future meetings; possibilities
include:

· A discussion of local database needs
· Content software (specifically mentioned the UW content software)
· Map digitalization
· The De Stefano article as a platform for discussion leading to an
examination of digital principles and infrastructure
· The Normandy  Report as a regular feature of the meeting.

"Follow-up" has been added as a future agenda item, meaning that we formally
keep
track of action items we've set for ourselves and report on our progress.


 The remainder of the meeting focused on the mass storage proposal coming
from Sara and Systems.   Travis described the configuration options and
pricing for a storage server.  The discussion ranged from possible hidden
costs (CH) to performance issues (JQ).

Initial calculation of costs (based on the Harmon example of a 300 megabyte
image resulting from the processing and archiving of a fragile glass plate),
in terms of digital storage would be approximately $2  per image (based on
an estimated cost of $8 per gigabyte).

Discussion ensued on the (large) issue of the potential amount of storage
needed by ongoing or planned library digital projects.  NH raised the issue
of limitations, both in terms of budget and personnel.

Travis estimated that the storage technology represented in the Systems
proposal would remain viable for the next 4-5 years. 

JQ expressed a preference for 99% availability of the storage server
(figuring a couple of hours of downtime/maintenance per week is workable).

JQ notes that THIS particular proposal assumes centralization, and that when
additional 
distributed storage options are needed they will probably involve different
sets of tradeoffs and different solutions that we are not addressing at this
time.

Carol summarizes that: 

1. we're not asking for a high-performance file server; this is being
conceived primarily as the storage point for the "master copy" of ourdigital
projects
2. availability - 2 hours downtime a week, maximum (already mentioned
elsewhere as JQ's suggestion but I thought we reached consensus on it)
3. redundant power supply desirable
4. understand how fast it will grow and take that into account in planning
(thus Normandy's survey), with the group sense that what  Systems outlined
here is probably realistically a short-term proposal (2-6 months)
5. understand how fast the hardware will be obsolete (the consensus on this
hardware being that it will be USABLE for 4 years but it might stop being
the primary server some time before then)
6. document procedures regarding configuration, backup, refreshing, etc. as
we go along
7. centralize the "master copy" storage to maximize efficiency of space and
staffing, recognizing that additional storage options may be distributed at
service points for ready access to "service copies"


JQ adds: There is consensus agreement as to the importance of offline and
offsite (tape) backup as the primary long-term archival storage, with the 
rotating storage being the working archival copy if you will.  Given the (I
think correct) tradeoffs Travis has made between cost and robustness, I 
think it's pretty likely that we'll lose (some/much of) the data on disk at
least once during the life of the system, and will need to depend on tape. 
So we have to have that right. 

JQ also notes: Centralization …. means both physical placement and, more
important, consistency in design and management.  At an extreme it could 
mean a hardware cookiecutter as we add units , but at least it means that
we'll add units that all run pretty much the same version of Linux and all 
are managed the same way, backed up the same way on a consistent schedule,
protected by the same type of UPS, have similar hardware architectures, 
etc.  To the extent that Travis can flesh out the details of this planned
consistency it will assist long-term expansion planning.  Another aspect of 
the consistency is that the Linux will be pretty much the same as (or a
subset of) that run on our many other Linux servers.



Discussion on the storage (digital warehouse) issue will be back on the
agenda at the first March meeting.  This discussion, however, triggered an
action item:  Normandy will conduct a quick survey of digital storage needs.
This is critical to any projection that we might do in terms of storage needs.

Next meeting of the group will be on Wednesday, 2/28, 1:30 p.m. in the Rowe
Conference Room.


Minutes taken by BF