BibTeX for papers by David Kotz; for complete/updated list see https://www.cs.dartmouth.edu/~kotz/research/papers.html @TechReport{carter:vesta, author = {Matthew P. Carter and David Kotz}, title = {{An Implementation of the Vesta Parallel File System API on the Galley Parallel File System}}, institution = {Dartmouth Computer Science}, year = 1998, month = {April}, number = {PCS-TR98-329}, copyright = {the authors}, URL = {https://www.cs.dartmouth.edu/~kotz/research/carter-vesta/index.html}, abstract = {To demonstrate the flexibility of the Galley parallel file system and to analyze the efficiency and flexibility of the Vesta parallel file system interface, we implemented Vesta's application-programming interface on top of Galley. We implemented the Vesta interface using Galley's file-access methods, whose design arose from extensive testing and characterization of the I/O requirements of scientific applications for high-performance multiprocessors. We used a parallel CPU, parallel I/O, out-of-core matrix-multiplication application to test the Vesta interface in both its ability to specify data access patterns and in its run-time efficiency. In spite of its powerful ability to specify the distribution of regular, non-overlapping data access patterns across disks, we found that the Vesta interface has some significant limitations. We discuss these limitations in detail in the paper, along with the performance results.}, } @TechReport{khanna:group, author = {Sanjay Khanna and David Kotz}, title = {{A Split-Phase Interface for Parallel File Systems}}, institution = {Dartmouth Computer Science}, year = 1997, month = {March}, number = {PCS-TR97-312}, copyright = {the authors}, URL = {https://www.cs.dartmouth.edu/~kotz/research/khanna-group/index.html}, abstract = {We describe the effects of a new user-level library for the Galley Parallel File System. This library allows some pre-existing sequential programs to make use of the Galley Parallel File System with minimal modification. It permits programs to efficiently use the parallel file system because the user-level library groups accesses together. We examine the performance of our library, and we show how code needs to be modified to use the library.}, } @Article{nieuwejaar:jgalley, author = {Nils Nieuwejaar and David Kotz}, title = {{The Galley Parallel File System}}, journal = {Parallel Computing}, year = 1997, month = {June}, volume = 23, number = 4, pages = {447--476}, publisher = {North-Holland (Elsevier Scientific)}, copyright = {North-Holland (Elsevier Scientific)}, DOI = {10.1016/S0167-8191(97)00009-4}, URL = {https://www.cs.dartmouth.edu/~kotz/research/nieuwejaar-jgalley/index.html}, abstract = {Most current multiprocessor file systems are designed to use multiple disks in parallel computing, using the high aggregate bandwidth to meet the growing I/O requirements of parallel scientific applications. Many multiprocessor file systems provide applications with a conventional Unix-like interface, allowing the application to access multiple disks transparently. This interface conceals the parallelism within the file system, increasing the ease of programmability, but making it difficult or impossible for sophisticated programmers and libraries to use knowledge about their I/O needs to exploit that parallelism. In addition to providing an insufficient interface, most current multiprocessor file systems are optimized for a different workload than they are being asked to support. We introduce Galley, a new parallel file system that is intended to efficiently support realistic scientific multiprocessor workloads. We discuss Galley's file structure and application interface, as well as the performance advantages offered by that interface.}, } @Article{kotz:flexibility, author = {David Kotz and Nils Nieuwejaar}, title = {{Flexibility and Performance of Parallel File Systems}}, journal = {ACM Operating Systems Review}, year = 1996, month = {April}, volume = 30, number = 2, pages = {63--73}, publisher = {ACM}, copyright = {the authors}, DOI = {10.1145/232302.232314}, URL = {https://www.cs.dartmouth.edu/~kotz/research/kotz-flexibility/index.html}, abstract = {Many scientific applications for high-performance multiprocessors have tremendous I/O requirements. As a result, the I/O system is often the limiting factor of application performance. Several new parallel file systems have been developed in recent years, each promising better performance for some class of parallel applications. As we gain experience with parallel computing, and parallel file systems in particular, it becomes increasingly clear that a single solution does not suit all applications. For example, it appears to be impossible to find a single appropriate interface, caching policy, file structure, or disk management strategy. Furthermore, the proliferation of file-system interfaces and abstractions make application portability a significant problem. \par We propose that the traditional functionality of parallel file systems be separated into two components: a fixed core that is standard on all platforms, encapsulating only primitive abstractions and interfaces, and a set of high-level libraries to provide a variety of abstractions and application-programmer interfaces (APIs). We think of this approach as the ``RISC'' of parallel file-system design. \par We present our current and next-generation file systems as examples of this structure. Their features, such as a three-dimensional file structure, strided read and write interfaces, and I/O-node programs, are specifically designed with the flexibility and performance necessary to support a wide range of applications.}, } @InProceedings{kotz:flexibility2, author = {David Kotz and Nils Nieuwejaar}, title = {{Flexibility and Performance of Parallel File Systems}}, booktitle = {{Proceedings of the International Conference of the Austrian Center for Parallel Computation (ACPC)}}, series = {Lecture Notes in Computer Science}, year = 1996, month = {September}, volume = 1127, pages = {1--11}, publisher = {Springer-Verlag}, copyright = {Springer-Verlag}, DOI = {10.1007/3-540-61695-0_1}, URL = {https://www.cs.dartmouth.edu/~kotz/research/kotz-flexibility2/index.html}, note = {Invited paper}, abstract = {As we gain experience with parallel file systems, it becomes increasingly clear that a single solution does not suit all applications. For example, it appears to be impossible to find a single appropriate interface, caching policy, file structure, or disk-management strategy. Furthermore, the proliferation of file-system interfaces and abstractions make applications difficult to port. \par We propose that the traditional functionality of parallel file systems be separated into two components: a fixed core that is standard on all platforms, encapsulating only primitive abstractions and interfaces, and a set of high-level libraries to provide a variety of abstractions and application-programmer interfaces (APIs). \par We present our current and next-generation file systems as examples of this structure. Their features, such as a three-dimensional file structure, strided read and write interfaces, and I/O-node programs, re specifically designed with the flexibility and performance necessary to support a wide range of applications.}, } @InProceedings{nieuwejaar:galley-perf, author = {Nils Nieuwejaar and David Kotz}, title = {{Performance of the Galley Parallel File System}}, booktitle = {{Proceedings of the Workshop on Input/Output in Parallel and Distributed Systems (IOPADS)}}, year = 1996, month = {May}, pages = {83--94}, publisher = {ACM}, copyright = {ACM}, address = {Philadelphia}, DOI = {10.1145/236017.236038}, URL = {https://www.cs.dartmouth.edu/~kotz/research/nieuwejaar-galley-perf/index.html}, abstract = {As the I/O needs of parallel scientific applications increase, file systems for multiprocessors are being designed to provide applications with parallel access to multiple disks. Many parallel file systems present applications with a conventional Unix-like interface that allows the application to access multiple disks transparently. This interface conceals the parallelism within the file system, which increases the ease of programmability, but makes it difficult or impossible for sophisticated programmers and libraries to use knowledge about their I/O needs to exploit that parallelism. Furthermore, most current parallel file systems are optimized for a different workload than they are being asked to support. We introduce Galley, a new parallel file system that is intended to efficiently support realistic parallel workloads. Initial experiments, reported in this paper, indicate that Galley is capable of providing high-performance I/O to applications that access data in patterns that have been observed to be common.}, } @InProceedings{nieuwejaar:galley, author = {Nils Nieuwejaar and David Kotz}, title = {{The Galley Parallel File System}}, booktitle = {{Proceedings of the ACM International Conference on Supercomputing (ICS)}}, year = 1996, month = {May}, pages = {374--381}, publisher = {ACM}, copyright = {ACM}, address = {Philadelphia}, DOI = {10.1145/237578.237639}, URL = {https://www.cs.dartmouth.edu/~kotz/research/nieuwejaar-galley/index.html}, abstract = {As the I/O needs of parallel scientific applications increase, file systems for multiprocessors are being designed to provide applications with parallel access to multiple disks. Many parallel file systems present applications with a conventional Unix-like interface that allows the application to access multiple disks transparently. This interface conceals the parallelism within the file system, which increases the ease of programmability, but makes it difficult or impossible for sophisticated programmers and libraries to use knowledge about their I/O needs to exploit that parallelism. Furthermore, most current parallel file systems are optimized for a different workload than they are being asked to support. We introduce Galley, a new parallel file system that is intended to efficiently support realistic parallel workloads. We discuss Galley's file structure and application interface, as well as an application that has been implemented using that interface.}, } @TechReport{nieuwejaar:jgalley-tr, author = {Nils Nieuwejaar and David Kotz}, title = {{The Galley Parallel File System}}, institution = {Dartmouth Computer Science}, year = 1996, month = {May}, number = {PCS-TR96-286}, copyright = {the authors}, URL = {https://www.cs.dartmouth.edu/~kotz/research/nieuwejaar-jgalley-tr/index.html}, abstract = {Most current multiprocessor file systems are designed to use multiple disks in parallel, using the high aggregate bandwidth to meet the growing I/O requirements of parallel scientific applications. Many multiprocessor file systems provide applications with a conventional Unix-like interface, allowing the application to access multiple disks transparently. This interface conceals the parallelism within the file system, increasing the ease of programmability, but making it difficult or impossible for sophisticated programmers and libraries to use knowledge about their I/O needs to exploit that parallelism. In addition to providing an insufficient interface, most current multiprocessor file systems are optimized for a different workload than they are being asked to support. We introduce Galley, a new parallel file system that is intended to efficiently support realistic scientific multiprocessor workloads. We discuss Galley's file structure and application interface, as well as the performance advantages offered by that interface.}, } @InCollection{nieuwejaar:strided2-book, author = {Nils Nieuwejaar and David Kotz}, title = {{Low-level Interfaces for High-level Parallel I/O}}, booktitle = {{Input/Output in Parallel and Distributed Computer Systems}}, editor = {Ravi Jain and John Werth and James C. Browne}, series = {The Kluwer International Series in Engineering and Computer Science}, year = 1996, volume = 362, chapter = 9, pages = {205--223}, publisher = {Kluwer Academic Publishers}, copyright = {Kluwer Academic Publishers}, ISBN13 = {978-1-4613-1401-1}, URL = {https://www.cs.dartmouth.edu/~kotz/research/nieuwejaar-strided2-book/index.html}, abstract = {As the I/O needs of parallel scientific applications increase, file systems for multiprocessors are being designed to provide applications with parallel access to multiple disks. Many parallel file systems present applications with a conventional Unix-like interface that allows the application to access multiple disks transparently. By tracing all the activity of a parallel file system in a production, scientific computing environment, we show that many applications exhibit highly regular, but non-consecutive I/O access patterns. Since the conventional interface does not provide an efficient method of describing these patterns, we present three extensions to the interface that support \emph{strided}, \emph{nested-strided}, and \emph{nested-batched} I/O requests. We show how these extensions can be used to express common access patterns.}, } @PhdThesis{nieuwejaar:thesis, author = {Nils A. Nieuwejaar}, title = {{Galley: A New Parallel File System for Parallel Applications}}, school = {Dartmouth College Computer Science}, year = 1996, month = {November}, copyright = {Nils A. Nieuwejaar}, address = {Hanover, NH}, URL = {https://www.cs.dartmouth.edu/~kotz/research/nieuwejaar-thesis/index.html}, note = {Available as Dartmouth Computer Science Technical Report PCS-TR96-300}, abstract = {Most current multiprocessor file systems are designed to use multiple disks in parallel, using the high aggregate bandwidth to meet the growing I/O requirements of parallel scientific applications. Most multiprocessor file systems provide applications with a conventional Unix-like interface, allowing the application to access those multiple disks transparently. This interface conceals the parallelism within the file system, increasing the ease of programmability, but making it difficult or impossible for sophisticated application and library programmers to use knowledge about their I/O to exploit that parallelism. In addition to providing an insufficient interface, most current multiprocessor file systems are optimized for a different workload than they are being asked to support. \par In this work we examine current multiprocessor file systems, as well as how those file systems are used by scientific applications. Contrary to the expectations of the designers of current parallel file systems, the workloads on those systems are dominated by requests to read and write small pieces of data. Furthermore, rather than being accessed sequentially and contiguously, as in uniprocessor and supercomputer workloads, files in multiprocessor file systems are accessed in regular, structured, but non-contiguous patterns. \par Based on our observations of multiprocessor workloads, we have designed Galley, a new parallel file system that is intended to efficiently support realistic scientific multiprocessor workloads. In this work, we introduce Galley and discuss its design and implementation. We describe Galley's new three-dimensional file structure and discuss how that structure can be used by parallel applications to achieve higher performance. We introduce several new data-access interfaces, which allow applications to explicitly describe the regular access patterns we found to be common in parallel file system workloads. We show how these new interfaces allow parallel applications to achieve tremendous increases in I/O performance. Finally, we discuss how Galley's new file structure and data-access interfaces can be useful in practice.}, } @TechReport{thomas:thesis, author = {Joel T. Thomas}, title = {{The Panda Array I/O Library on the Galley Parallel File System}}, institution = {Dartmouth Computer Science}, year = 1996, month = {June}, number = {PCS-TR96-288}, copyright = {the author}, address = {Hanover, NH}, URL = {https://www.cs.dartmouth.edu/~kotz/research/thomas-thesis/index.html}, note = {Available as Dartmouth Computer Science Technical Report PCS-TR96-288}, abstract = {The Panda Array I/O library, created at the University of Illinois, Urbana-Champaign, was built especially to address the needs of high-performance scientific applications. I/O has been one of the most frustrating bottlenecks to high performance for quite some time, and the Panda project is an attempt to ameliorate this problem while still providing the user with a simple, high-level interface. The Galley File System, with its hierarchical structure of files and strided requests, is another attempt at addressing the performance problem. My project was to redesign the Panda Array library for use on the Galley file system. This project involved porting Panda's three main functions: a checkpoint function for writing a large array periodically for 'safekeeping,' a restart function that would allow a checkpointed file to be read back in, and finally a timestep function that would allow the user to write a group of large arrays several times in a sequence. Panda supports several different distributions in both the compute-node memories and I/O-node disks. \par We have found that the Galley File System provides a good environment on which to build high-performance libraries, and that the mesh of Panda and Galley was a successful combination.}, } @TechReport{nieuwejaar:strided2-tr, author = {Nils Nieuwejaar and David Kotz}, title = {{Low-level Interfaces for High-level Parallel I/O}}, institution = {Dartmouth Computer Science}, year = 1995, month = {March}, number = {PCS-TR95-253}, copyright = {the authors}, URL = {https://www.cs.dartmouth.edu/~kotz/research/nieuwejaar-strided2-tr/index.html}, note = {Revised 4/18/95 and appeared in IOPADS workshop at IPPS'95}, abstract = {As the I/O needs of parallel scientific applications increase, file systems for multiprocessors are being designed to provide applications with parallel access to multiple disks. Many parallel file systems present applications with a conventional Unix-like interface that allows the application to access multiple disks transparently. By tracing all the activity of a parallel file system in a production, scientific computing environment, we show that many applications exhibit highly regular, but non-consecutive I/O access patterns. Since the conventional interface does not provide an efficient method of describing these patterns, we present three extensions to the interface that support \emph{strided}, \emph{nested-strided}, and \emph{nested-batched} I/O requests. We show how these extensions can be used to express common access patterns.}, } @InProceedings{nieuwejaar:strided2, author = {Nils Nieuwejaar and David Kotz}, title = {{Low-level Interfaces for High-level Parallel I/O}}, booktitle = {{Proceedings of the IPPS Workshop on Input/Output in Parallel and Distributed Systems (IOPADS)}}, year = 1995, month = {April}, pages = {47--62}, copyright = {the authors}, URL = {https://www.cs.dartmouth.edu/~kotz/research/nieuwejaar-strided2/index.html}, abstract = {As the I/O needs of parallel scientific applications increase, file systems for multiprocessors are being designed to provide applications with parallel access to multiple disks. Many parallel file systems present applications with a conventional Unix-like interface that allows the application to access multiple disks transparently. By tracing all the activity of a parallel file system in a production, scientific computing environment, we show that many applications exhibit highly regular, but non-consecutive I/O access patterns. Since the conventional interface does not provide an efficient method of describing these patterns, we present three extensions to the interface that support \emph{strided}, \emph{nested-strided}, and \emph{nested-batched} I/O requests. We show how these extensions can be used to express common access patterns.}, } @TechReport{nieuwejaar:strided, author = {Nils Nieuwejaar and David Kotz}, title = {{A Multiprocessor Extension to the Conventional File System Interface}}, institution = {Dartmouth Computer Science}, year = 1994, month = {September}, number = {PCS-TR94-230}, copyright = {the authors}, URL = {https://www.cs.dartmouth.edu/~kotz/research/nieuwejaar-strided/index.html}, abstract = {As the I/O needs of parallel scientific applications increase, file systems for multiprocessors are being designed to provide applications with parallel access to multiple disks. Many parallel file systems present applications with a conventional Unix-like interface that allows the application to access multiple disks transparently. By tracing all the activity of a parallel file system in a production, scientific computing environment, we show that many applications exhibit highly regular, but non-consecutive I/O access patterns. Since the conventional interface does not provide an efficient method of describing these patterns, we present an extension which supports \emph{strided} and \emph{nested-strided} I/O requests.}, }