309 lines
9.9 KiB
HTML
309 lines
9.9 KiB
HTML
<HTML VERSION="2.0">
|
|
<HEAD>
|
|
<!-- WEBMAGIC VERSION NUMBER="1.0" -->
|
|
<!-- WEBMAGIC TRANSLATION NAME="ServerRoot" SRC="/usr/netsite-docs/" DST="/" -->
|
|
<!-- WEBMAGIC TRANSLATION NAME="ProjectRoot" SRC="/usr/people/bobg/Web/PoliciesAndProcesses/" DST="" -->
|
|
<TITLE> Array Services Project Page</TITLE>
|
|
<!-- Changed by: Rob Bradshaw, 2-Jul-1996 -->
|
|
</HEAD>
|
|
<BODY>
|
|
|
|
<H1>Project Page - Array Services</H1>
|
|
|
|
<HR>
|
|
|
|
<P>Rob Bradshaw, <A HREF="mailto:rdb@engr.sgi.com">rdb@engr.sgi.com</A>
|
|
|
|
<!-- After your project page has been completed, check it into the top of your source tree. Project pages are release specific so it is the best location. Send mail to bobg@engr to have the project page included in the various project page groups. -->
|
|
|
|
<H3>1. Identification:</H3>
|
|
|
|
<H4>1.1 Project Code name:</H4>
|
|
<UL>
|
|
<LI>none (or just <I>array services</I> if you like)
|
|
</UL>
|
|
|
|
<H4>1.2 Product name (if known):</H4>
|
|
<UL>
|
|
<LI><B>arraysvcs</B> in inst, <B>Array Services</B> in normal english.
|
|
</UL>
|
|
|
|
<H4>1.3 Engineering manager:</H4>
|
|
<UL>
|
|
<LI><A HREF="mailto:ajitd@engr.sgi.com">Ajit Dandapani</A>
|
|
</UL>
|
|
|
|
<H4>1.4 Marketing manager:</H4>
|
|
<UL>
|
|
<LI>???
|
|
</UL>
|
|
|
|
<H4>1.5 Project software architects/lead designers:</H4>
|
|
<UL>
|
|
<LI><A HREF="mailto:rdb@engr.sgi.com">Rob Bradshaw</A>
|
|
</UL>
|
|
|
|
<H4>1.6 Who outside the project is familiar with the project's technical details?</H4>
|
|
<UL>
|
|
<LI>Array Technology Group
|
|
</UL>
|
|
|
|
<H4>1.7 What parts of the source tree contain the results of this project?</H4>
|
|
Currently:
|
|
<UL>
|
|
<LI>/proj/array_3.0/isms/array/arraysvcs
|
|
</UL>
|
|
<P>
|
|
This would be changed to:
|
|
<UL>
|
|
<LI>/proj/ficus/isms/irix/lib/libarray
|
|
<LI>/proj/ficus/isms/irix/cmd/array/*
|
|
<LI>/proj/ficus/isms/irix/man/man{1,1m,3,4,5}
|
|
</UL>
|
|
|
|
<H4>1.8 What sub-projects contribute to this project?</H4>
|
|
<UL>
|
|
<LI>none
|
|
</UL>
|
|
|
|
<H3>2. Goals:</H3>
|
|
|
|
<H4>2.1 What problem (or problems) is this project solving and for whom?</H4>
|
|
<UL>
|
|
<LI>The <B>arraysvcs</B> product already ships to customers as part of the
|
|
Array 1.0 and 2.0 software packages, which is typically given to sites that
|
|
have purchased [Power]Challenge arrays.
|
|
However, There are several third party and internal software products
|
|
that either currently or will eventually make use of array services on
|
|
systems that are not necessarily formal "arrays".
|
|
Although the Array software package is available to any server
|
|
customer free for the asking, this is inconvenient and confusing for
|
|
customers and annoying to ISVs. Therefore, we would like to make
|
|
array services available as part of the base IRIX software release.
|
|
|
|
<P>
|
|
It is worth pointing out that although the Array software package is
|
|
generally only given to high-end server customers, the array services
|
|
software itself is useful on <I>any</I> system in the product line
|
|
that runs IRIX 6.2 or better, and in fact a couple of ISVs have
|
|
expressed interest specifically in using array services on low-end systems.
|
|
The software is currently tested and running on low-end platforms.
|
|
|
|
<P>
|
|
Note that until there is another all-platforms release of IRIX, it would
|
|
still be necessary to include the array services software as part of
|
|
the Array package as well.
|
|
Until that time, our intention is that the array services software that
|
|
ships as part of IRIX would always be identical to the array services
|
|
software that has <I>already</I> been shipped as part of the most recent Array
|
|
package.
|
|
</UL>
|
|
|
|
<H4>2.2 What specific features or functions are being created?</H4>
|
|
<UL>
|
|
<LI>Array services consists of a library, a daemon, and several user commands
|
|
that allow groups of related processes to be managed as a single unit, even
|
|
if those processes reside on different physical machines.
|
|
See 5.1 for more details.
|
|
<P>
|
|
The array services software is fairly self-contained, and should not affect
|
|
any other parts of IRIX.
|
|
</UL>
|
|
|
|
<H4>2.3 What user documentation will be produced?</H4>
|
|
<UL>
|
|
<LI>Lots of
|
|
<A HREF="http://uniscan.engr.sgi.com/~rdb/Array/ManPages.html">man pages</A>
|
|
and the usual relnotes.
|
|
</UL>
|
|
|
|
<H4>2.4 What are the quantitative performance and resource usage goals for the product?</H4>
|
|
<UL>
|
|
<LI>There are no particular quantitative performance goals; qualitatively,
|
|
the user commands should not be "painfully slow".
|
|
<P>
|
|
<LI>In terms of memory usage, the array services daemon should
|
|
not take significantly more system resources than most
|
|
other system daemons (e.g. inetd), particularly if the machine is
|
|
not a member of a formal "array".
|
|
Currently, these goals are being met.
|
|
On a 32-bit 6.2 Indy system with a very basic array configuration, "ps"
|
|
shows:
|
|
<PRE>
|
|
F S UID PID PPID C PRI NI P SZ:RSS WCHAN TTY TIME CMD
|
|
b0 S 0 475 1 0 60 20 * 394:4 8833631c ? 0:00 arrayd
|
|
b0 S 0 227 1 0 60 20 * 344:18 883362bc ? 0:02 inetd
|
|
</PRE>
|
|
<P>
|
|
On a 64-bit system that is part of a full-blown array configuration:
|
|
<PRE>
|
|
F S UID PID PPID C PRI NI P SZ:RSS WCHAN TTY TIME CMD
|
|
30 S 0 685 1 0 60 20 * 104:52 1055570 ? 0:03 arrayd
|
|
30 S 0 269 1 0 60 20 * 88:20 1054870 ? 0:21 inetd
|
|
</PRE>
|
|
<P>
|
|
Note that for many low end systems, it may not be necessary to run an array
|
|
services daemon at all, in which case memory usage is 0.
|
|
<P>
|
|
<LI>The disk usage for a "fully loaded" installation of array services should
|
|
not exceed a few megabytes, and in fact it currently only takes about 1.75MB.
|
|
A "minimal" installation of just O32/N32 DSO's takes about 250K.
|
|
<P>
|
|
<LI>In general, array services should have no discernible impact on overall
|
|
system performance, and this in fact seems to be the case on existing
|
|
installations.
|
|
</UL>
|
|
|
|
<H4>2.5 What tests are planned to measure performance?</H4>
|
|
<UL>
|
|
<LI>Empirical observation.
|
|
</UL>
|
|
|
|
<H4>2.6 What other functionality will regress in performance due to these changes?</H4>
|
|
<UL>
|
|
<LI>none
|
|
</UL>
|
|
|
|
<H4>2.7 What are this project's goals for reliability, testability, robustness, maintainability?</H4>
|
|
<UL>
|
|
<LI>"The usual".
|
|
</UL>
|
|
|
|
<H4>2.8 What tests are planned to assure functionality and reliability.</H4>
|
|
<UL>
|
|
<LI>Same as the Array software package.
|
|
Note that because the version of array services that ships
|
|
with ficus will be one that has already shipped as part of the latest Array
|
|
software package release, it will have already gone through some amount of
|
|
testing in customer hands.
|
|
</UL>
|
|
|
|
<H4>2.9 What problems are NOT going to be addressed by this project that someone might expect to be addressed?</H4>
|
|
<UL>
|
|
<LI>I can't think of any.
|
|
</UL>
|
|
|
|
<H4>2.10 What is the target market user expertise?</H4>
|
|
<UL>
|
|
<LI>Sysadmin expertise or better. This is not intended for use by
|
|
naive end-users (nor is it likely to be of any interest to them).
|
|
</UL>
|
|
|
|
<H3>3. Dependencies:</H3>
|
|
|
|
<H4>3.1 What will be required of the customer to use this product (investment, training, reconfiguration, etc.)?</H4>
|
|
<UL>
|
|
<LI>Customers that would actually like to take advantage of array services
|
|
will need to set up a
|
|
configuration file and use <I>chkconfig</I> to turn array services on.
|
|
For simple configurations, a tool is provided to do all of this with a
|
|
single command.
|
|
<LI>If array services is being installed simply to satisfy a prereq
|
|
from some other software product, no training/configuration/etc. is required
|
|
at all.
|
|
(Note that this would not necessarily be a pointless prereq - there are parts
|
|
of array services that are still useful even if it is unconfigured.)
|
|
</UL>
|
|
|
|
<H4>3.2 Which projects depend on the results of this project?</H4>
|
|
<UL>
|
|
<LI><B>PerfAcct II</B>, an accounting software package by Instrumental Inc.
|
|
<LI><B>LSF</B>, a batch processing facility by Genias.
|
|
<LI><B>NQE</B>, another batch processing facility by CraySoft.
|
|
<LI><B>CPR</B>, a checkpoint/restart facility being developed here at SGI
|
|
for Ficus.
|
|
<P>
|
|
Note that except for CPR, these projects are all third-party products.
|
|
</UL>
|
|
|
|
<H4>3.3 Which projects does this project depend upon?</H4>
|
|
<UL>
|
|
<LI>none
|
|
</UL>
|
|
|
|
<H4>3.4 Which platforms will be supported and which will not?</H4>
|
|
<UL>
|
|
<LI>Array services will run on any platform that has IRIX 6.2 or better
|
|
installed.
|
|
</UL>
|
|
|
|
<H3>4. Schedule:</H3>
|
|
<H4>4.1 Provide a schedule with the following milestones:</H4>
|
|
<PRE>
|
|
<I>(following assumes Array 2.0 array services ships with ficus)</I>
|
|
|
|
done Design Complete
|
|
done Coding Complete
|
|
done Integration Complete
|
|
done System Test Complete
|
|
done Alpha Test Cycle
|
|
done Early Customer Access Cycle
|
|
done Beta Test Cycle
|
|
done Manufacturing
|
|
done Release
|
|
done First Customer Ship
|
|
</PRE>
|
|
|
|
<H4>4.2 What are the major risks to achieving all goals while meeting this schedule?</H4>
|
|
<UL>
|
|
<LI>Since the software is ready, there should be none.
|
|
</UL>
|
|
|
|
<H4>4.3 Are you on schedule?</H4>
|
|
<UL>
|
|
<LI>Yes.
|
|
</UL>
|
|
|
|
<H3>5. Documents:</H3>
|
|
<H4>5.1 How can I obtain the documents that describe the functionality, performance, architecture, interfaces, design of this product?</H4>
|
|
<UL>
|
|
<LI>An overview of array services can be found in the
|
|
<A HREF="http://homegrown.engr.sgi.com/cgi-bin/yam2h?topic=array_services§ion=5">array services man page</A>
|
|
that ships as part of array services.
|
|
<LI>For more information, I have everything online
|
|
<A HREF="http://uniscan.engr.sgi.com/~rdb/Array/index.html">here</A>.
|
|
</UL>
|
|
|
|
<H4>5.2 How can I obtain the documents that represent the Test Plan and Documentation Plan for this product?</H4>
|
|
<UL>
|
|
<LI>n/a
|
|
</UL>
|
|
|
|
<H3>6. Contracts and Licenses</H3>
|
|
|
|
<H4>6.1 What contracts exist for third party software and what is the approval cycle?</H4>
|
|
<UL>
|
|
<LI>none
|
|
</UL>
|
|
|
|
<H4>6.2 Are there any built in assumptions in the contract regarding distribution methods and quantities?</H4>
|
|
<UL>
|
|
<LI>n/a
|
|
</UL>
|
|
|
|
<H4>6.3 What is the royalty structure?</H4>
|
|
<UL>
|
|
<LI>n/a
|
|
</UL>
|
|
|
|
<H4>6.4 How are customers under support contract to be managed?</H4>
|
|
<UL>
|
|
<LI>as per ficus
|
|
</UL>
|
|
|
|
<H4>6.5 What are the contract start and stop dates?</H4>
|
|
<UL>
|
|
<LI>n/a
|
|
</UL>
|
|
|
|
<H3>7. Miscellaneous:</H3>
|
|
<H4>7.1 Anything else you think people should know about the project?</H4>
|
|
<UL>
|
|
<LI>Nope.
|
|
</UL>
|
|
|
|
<H3>8.0 Software Release Request (pointer)</H3>
|
|
<I>n/a</I>
|
|
</BODY>
|
|
</HTML>
|