Lately you may have begun hearing about High Performance NFS offerings and standards. But we all "know" NFS is not scalable. So what does High Performance NFS mean? FPGA implementation of parts of the file system? Really big caches? RDMA embedded in the RPC mechanism? Multiple filers exporting the same files? Delegations for file layout enabling clients to directly access storage devices/servers in parallel? This panel will address this question with enough opinions to ensure that attendees learn much more about the alternatives and strategies without being able to say it is just one thing. Yet.

Blue Gene/L is currently the world's fastest and most scalable supercomputer. It has demonstrated essentially linear scaling all the way to 131,072 processors in several benchmarks and real applications. The operating systems for the compute and I/O nodes of Blue Gene/L, are among the components responsible for that scalability. Compute nodes are dedicated to running application processes, whereas I/O nodes are dedicated to performing system functions. The operating systems adopted for each of these nodes reflect this separation of function. Compute nodes run a lightweight operating system called the compute node kernel. I/O nodes run a port of the Linux operating system. This paper discusses the architecture and design of this solution for Blue Gene/L in the context of the hardware characteristics that led to the design decisions. It also explains and demonstrates how those decisions are instrumental in achieving the performance and scalability for which Blue Gene/L is famous.

We investigate here, both theoretically and by demonstration, scaling file storage to the very widest possible extents. We use IBM's GPFS file system, with extensions developed by the San Diego Supercomputer Center in collaboration with IBM. Geographically, the file system extends across the United States, including Pittsburgh, Illinois, and San Diego, California, with the TeraGrid 40 Gb/s backbone providing the wide area network connectivity. We show the results from two demonstrations, at each of the past two supercomputing conferences, SC03 in Phoenix, Arizona, and SC04 in Pittsburgh, Pennsylvania. The second demonstration was purposely designed to presage an intended production facility across the National Science Foundation's TeraGrid.

This paper describes QuickSilver, developed at the IBM Almaden Research Center, which usesatomic transactionsas a unified failure recovery mechanism for a client-server structured distributed system. Transactions allow failure atomicity for related activities at a single server or at a number of independent servers. Rather than bundling transaction management into a dedicated language or recoverable object manager, Quicksilver exposes the basic commit protocol and log recovery primitives, allowing clients and servers to tailor their recovery techniques to their specific needs. Servers can implement their own log recovery protocols rather than being required to use a system-defined protocol. These decisions allow servers to make their own choices to balance simplicity, efficiency, and recoverability.

One price of extensibility and distribution, as implemented in QuickSilver, is a more complicated set of failure modes, and the consequent necessity of dealing with them. In traditional operating systems, services (e.g., file, display) are intrinsic pieces of the kernel. Process state is maintained in kernel tables, and the kernel contains explicit cleanup code (e.g., to close files, reclaim memory, and get rid of process images after hardware or software failures). QuickSilver, however, is structured according to the client-server model, and as in many systems of its type, system services are implemented by user-level processes that maintain a substantial amount of client process state. Examples of this state are the open files, screen windows, address space, etc., belonging to a process. Failure resilience in such an environment requires that clients and servers be aware of problems involving each other. Examples of the way one would like the system to behave include having files closed and windows removed from the screen when a client terminates, and having clients see bad return codes (rather than hanging) when a file server crashes. This motivates a number of design goals:

The design and operation of a new class of hardware-based pattern matchers, such as would be used in a backended database processor in a full-text or other retrieval system, is presented. This recognizer is based on a unique implementation technique for finite state automata consisting of partitioning the state table among a number of simple digital machines. It avoids the problems generally associated with implementing finite state machines, such as large state table memories, complex control mechanisms, and state encodings. Because it consists primarily of memory, with its high regularity and density, needs only limited static interconnections, and operates at a relatively low speed, it can be easily constructed using integrated circuit techniques. After a brief discussion of other pattern-matching hardware, the structure and operation of the partitioned finite state automaton is given, along with a simplified discussion of how the state tables are partitioned. The expected performance of the resulting system and the state table partitioning programs is then discussed.

Relational database systems are attracting great interest from potential users outside the traditional areas in which such systems have been employed. Features of modern relational systems such as powerful query facilities, data and device independence, concurrency control, and recovery are useful in applications such as engineering design, office automation, and graphics. However, such applications place demands on the system that it must be extended to handle. This paper identifies three of these demands: storing non-coded information of arbitrary length within the database, dealing with aggregate objects as a unit, and improving support for interactive access. Additions to System R, a prototypical relational system, are introduced to satisfy these demands: long fields, for storing non-coded data, and complex objects, which declare the semantic relationships among data items and provide a means for adequately supporting interactive access.