GEMS : FAQ

Basics

• What is required to start using GEMS?
• What is required to add my resources to GEMS?
• What is required to set up a new GEMS installation?
• Where can I get GEMS?

GEMS vs. other tools

• What exactly is GEMS addressing?
• How does GEMS compare to
  • Globus
  • Condor
  • Chirp
  • SRB
  • OceanStore

GEMS Internals

• What language is GEMS written in?
• Can I get the source for GEMS?
• Can I get CVS access to GEMS?
• Do I have to use Globus to use GEMS?
• What database servers can be used?

To run the GEMS clients and connect to a GEMS server installation, you will need the Java 1.4.2 JRE, which should already be installed on typical Linux systems, and is available for Windows and other systems as well. Running GEMS simply requires the download of a Java JAR file, no installation scripts need to be run! See the Manuals for more information.

Adding storage resources to GEMS is easy, you don't even need root access or to add users to the system! To add your computer to the GEMS network as a volunteer server, you first need to install and run the Chirp server, which is available for Linux and other systems. Specify the appropriate Chirp Catalog for reporting. Then, create a /GEMS directory, and simply grant permissions to the appropriate GEMS server process. See the Manuals for more information.

To start a GEMS server from scratch, you will need the Java JDK 1.5.0, PostgreSQL, and the Chirp Catalog service. Once these building blocks are in place, download the GEMS distribution (source or pre-compiled) and you're ready to go!

• Most users will want to simply download the latest software from our Downloads page.
• You may also checkout the latest version from CVS from GEMS @ SourceForge .
• From inside a script in a compute system such as Condor, it may be useful to use a tool such as wget to retrieve the GEMS client JAR, and then use GEMS to retrieve the rest of your files before computation. The metadata and replica oriented aspects of GEMS make it a powerful tool for such situations.

GEMS benefits scientific users who would like to pool existing storage resources together to create a larger, unified workspace for simulation that allows storage owners to maintain control of their systems, including the ability to revoke service.

• Globus:
  Since GEMS is a replica location service and uses Globus security, it may be compared to systems such as RLS. However, GEMS manages metadata internally, and automatically audits the availability of replicas. Additionally, GEMS allows data-centric simulation techniques to avoid explicit file staging.
• Condor:
  GEMS is not a compute system. However, GEMS shares many of the goals of the Condor system, such as the ability to catalog and make matches between requests for service and service providers. Current scientific usage shows that combining Condor with GEMS creates a powerful, data-centric compute system that allows for matchmaking on both the resource and the available data sets.
• Chirp:
  GEMS builds atop the Chirp system, effectively federating large numbers of autonomous Chirp services into a unified, searchable, survivable storage system.
• SRB:
  GEMS shares many goals with the SRB system. However, installation of additional storage in GEMS is a lightweight operation. Additionally, GEMS is designed to support very large counts of storage servers, and intelligently respond to failures. GEMS also does not deal with the concurrency of data sets.
• OceanStore:
  GEMS does not use RAID style striping in its file storage, an overlay network, or cryptography.

GEMS is all Java. Helper scripts are included, compatible with sh. Some optional administration tools are designed for the Beanshell.

Yes, see our SourceForge page.

Send requests to jwozniak@nd.edu.

No. GEMS supports all of the Chirp authentication methods, including Unix, hostname, Globus and Kerberos.

GEMS has only been tested using Postgres but does not rely on Postgres-specific features.