DWorFS: File System Support for Legacy Applications in DISCWorld

DWorFS: File System Support for Legacy Applications in DISCWorld

Craig J. Patten, F. A. Vaughan, K. A. Hawick and A. L. Brown 
{cjp,francis,khawick,fred}@cs.adelaide.edu.au
Distributed High Performance Computing Group
Department of Computer Science
University of Adelaide
Adelaide, SA 5005, Australia

Technical Report DHPC-032
January 1998

1. Introduction

This document describes a system we are developing to support legacy and commercial applications in the DISCWorld [haw98] distributed computing environment. Distributed high-performance computing systems, often referred to as metacomputing [cat92] systems, present many challenges not only in their design and implementation, but in the harnessing of the resultant collective resource. Supporting legacy and commercial applications not specifically designed for use in a given metacomputing system is one such challenge.

The DISCWorld File System, or DWorFS, which we are developing, provides a standard file system interface to an heterogeneous collection of distributed and/or hierarchical storage resources. DWorFS embeds a storage service Application Programming Interface (API) into the standard file system interface. This allows users of legacy and commercial applications more flexibility and higher performance in the use of their applications, without requiring the modification of their often unavailable source code to use custom storage service APIs.

2. DWorFS Rationale

Storage in metacomputing systems often consists of a mixture of heterogeneous distributed and hierarchical media, at a number of levels in the storage hierarchy. There are generally two ways to access such storage. One is through a file system layer, which abstracts over the physical layout of data by providing a standard, uniform file system interface. However high-performance applications using such systems cannot realise the full performance potential of the underlying hardware, because they lack flexibility in spatial and temporal data layout and tiling.

The other option for storage access is to provide applications with a storage system interface featuring more functionality than a standard file system. For example, explicit calls in an API for prefetching and data tiling. Since these systems allow applications which use them to customise the manner in which they store and retrieve data, higher performance can generally be achieved. The problem with these systems is that they are usually custom-designed, and therefore legacy applications which use the normal file system interface are unable to use them. It is important to support these applications without requiring access to their source code.


3. DWorFS Semantics and Design

The prime design feature of DWorFS is the use of the standard file system interface. Applications accessing data through DWorFS use virtual directories and filenames to specify to DWorFS the required data and options. It is the task of DWorFS to perform whatever processing is necessary to format the data as desired by the application. This concept of virtual pathname components is also used in other systems [bla93, gif91, cat91] which export a standard file system interface to a more complex underlying system.

The purpose of these virtual pathnames is to attach semantics relating to the desired type of requested data to the pathnames themselves. For example, the specification of geometries and file formats in pathnames when accessing an image repository. This allows the user of the application more flexibility in the use of such a repository.

The syntax and semantics of these virtual pathname components in DWorFS are dataset-dependent, and in future versions of the system, will be user-configurable through the DISCWorld infrastructure. For our current prototype, we are using traditional tree-structured virtual pathnames, however as future work we intend to explore alternatives such as name-value pairs, as used in the Common Gateway Interface [cgi95].

Some of our driving applications for DISCWorld involve the processing of bulk regular data, for example satellite imagery. We therefore present the following example usage of DWorFS, in the context of a GMS-5 [gms89] satellite imagery repository.

3.1 DWorFS Example Usage: Cloud Cover Application

As an example, we describe the use of DWorFS to provide GMS-5 satellite imagery to an application which calculates the percentage of cloud cover in a given GMS-5 image. The requirements of this application on the GMS-5 image repository are fairly straightforward - it opens two GMS-5 images, one for the visual channel and the other for the infrared channel. The pathnames in this example take the form: 
/gms5/dates/channels/geometry[.formats]
Note that the use of "/" as the internal field separator (IFS) is purely arbitrary. The Network File System (NFS) [sun89, san85], our choice for DWorFS' external interface, is IFS-independent.

For example, if the cloud cover application attempted to read from the following filename through DWorFS: 

/gms5/199801011200/vis/250x200+950+1700.pgm
The client will be presented with a file handle for a 250x200 Portable Greymap (PGM) [pos89] image file cut out from (950,1700) to (1200,1900) in the visual channel of a GMS-5 image from the 1st January 1998 at 1200 UTC - an image of South Australia. The file transformations occur automatically; in this case the crop, and conversion from Hierarchical Data Format (HDF) [hdf97], in which the GMS-5 satellite imagery is stored in on our system, to PGM format. The use of arbitrary cropping implies that the operation of listing a directory such as 
/gms5/199801011200/vis/
is infeasible because of the large number of possible entries, and is not implemented. It is important to note that the data transformations which can be performed are constrained by the fact that a virtual file's size must be calculable without the actual generation of the deliverable data. For example, transformations to image formats which utilise compression would be infeasible in DWorFS, because the compression ratio for any given file cannot be known in advance.

4. DWorFS Implementation

We are in the process of implementing a DWorFS prototype on the Unix [rit74] operating system using the C [ker88] programming language. The primary implementation platform for the associated DISCWorld infrastructure is Java [gos96].

4.1 DWorFS External Interface

Two obvious candidates presented themselves for the external interface of DWorFS; the Network File System (NFS), or the Virtual File System (VFS) [kle86]. NFS allows clients to access storage across a network using standard file system semantics as defined in Network Working Group Request for Comments (RFC) documents 1094 [sun89] and 1813 [sun95, paw94]. VFS provides file system implementors with a standard operating system interface, abstracting over the underlying storage model.

NFS support exists on many platforms, from supercomputers to personal computers, whereas support for VFS exists primarily on Unix systems, and its use generally requires kernel modifications. User-level NFS servers are far less platform-dependent, and have been used before in the Cryptographic File System [bla93], the Semantic File System [gif91], ATTIC [cat91], and a number of other systems. For these reasons we have chosen NFS as the external interface for DWorFS.

4.2 DWorFS Internal Structure

The internal processing in DWorFS occurs in a layer under the NFS server in the DWorFS daemon program. NFS requests are transferred to this layer, which performs the actual processing and supplies responses up through the NFS interface. Currently the server is specific to our GMS-5 image repository, but we plan to extend the system to be extensible to, and user-configurable for, arbitrary datasets.

5. Conclusions

DWorFS is a mechanism through which we intend to support legacy and commercial applications in the DISCWorld distributed computing infrastructure. We have implemented a prototype, and intend to pursue future work in functionality, performance, and portability.

6. Future Work

6.1 Prefetching in DWorFS

Our current DWorFS prototype has no prefetching capabilities, however we are exploring the possibilities for this functionality. One option is to manipulate the time of last data modification file attribute to implement data prefetching. When DWorFS is presented with a request to set this attribute for a virtual file, the request is interpreted as a notification that the file specified will likely be required at the date and time specified; if the date/time is not in the future it is ignored. The required client functionality to submit such requests is in the Unix touch program, and in the cases where no common program exists which can issue the request, a DISCWorld applet will provide the functionality by directly communicating with DWorFS.

6.2 Writing data through DWorFS

The DWorFS prototype is read-only. We are exploring the motivations and issues related to writing data through DWorFS, including the specification of tiling and layout information within virtual pathnames.

6.3 Alternative Virtual Pathname Syntaxes and Semantics

As stated previously, virtual pathnames used in the DWorFS prototype are tree-structured. We are also looking at alternative methods of data specification, such as name-value pairs similar to those used in the Common Gateway Interface (CGI) [cgi95]. We are also researching fuller functionality in the pathnames, primarily tiling and layout specifications.

6.4 NFS Multi-Component Lookup

Normally NFS clients can only lookup one pathname component per request. This has the obvious detrimental effect where large network latencies are involved, and has been addressed in later NFS servers with WebNFS/Multi-Component Lookup (MCL) [sun96a, sun96b, sun97] functionality. This allows a full pathname lookup to be sent in one NFS request, improving performance. In the future we intend to add WebNFS/MCL support to DWorFS.

Acknowledgements

This work is being carried out as part of the Distributed High Performance Computing Infrastructure (DHPC-I) project of the Research Data Networks Cooperative Research Center (RDN CRC) and is managed under the On-Line Data Archives Program of the Advanced Computational Systems CRC. RDN and ACSys are established under the Australian Government's CRC Program.

References

[bla93] Matt Blaze, A Cryptographic File System for Unix, In Proceedings of the First ACM Conference on Communications and Computing Security, Fairfax, Virginia, November 1993.

[cat91] Vincent Cate and Thomas Gross, Combining the Concepts of Compression and Caching for a Two-Level Filesystem, In Proceedings of the Fourth Conference on Architectural Support for Programming Languages and Operating Systems, Santa Clara, California, April 1992, pp. 200-211.

[cat92] C. Catlett, and L. Smarr, Metacomputing, Communications of the ACM, 35 (1992), pp. 44-52.

[cgi95] National Center for Supercomputing Applications, The CGI Specification, 1995.

[gif91] David K. Gifford, Pierre Jouvelot, Mark A. Sheldon, James W. O'Toole, Jr., Semantic File Systems, In Proceedings of the Thirteenth Symposium on Operating Systems Principles, 1991.

[gms89] Japanese Meteorological Satellite Center, The GMS User's Guide, Second Edition, 1989.

[gos96] James Gosling, Bill Joy, and Guy Steele, The Java Language Specification, Addison-Wesley JavaSoft Series, 1996.

[haw98] K. A. Hawick, et al., DISCWorld: An Integrated Data Environment for Distributed High-Performance Computing, Submitted to the Fifth IDEA Conference, Fremantle, Australia, January 1998.

[hdf97] National Center for Supercomputing Applications, HDF Reference Manual, Version 4.1r1, April 1997.

[ker88] Brian Kernighan and Dennis Ritchie, The C Programming Language, Prentice Hall Software Series, 1988.

[kle86] S. R. Kleiman, Vnodes: An Architecture for Multiple File System Types in Sun Unix, In Proceedings of the USENIX 1986 Winter Conference, 1986, pp. 238-247.

[paw94] Brian Pawlowski, Chet Juszczak, Peter Staubach, Carl Smith, Diane Lebel, David Hitz, NFS Version 3 Design and Implementation, In Proceedings of the USENIX 1994 Summer Conference, June 1994.

[pos89] Jef Poskanzer, The Extended Portable Bitmap Toolkit, 1989.

[rit74] D. M. Ritchie and K. Thompson, The UNIX Time-Sharing System, Communications of the ACM, 17(7):365-375, July 1974.

[san85] R. Sandberg, D. Goldberg, S. Kleiman, D. Walsh, and B. Lyon, Design and Implementation of the Sun Network Filesystem, In Proceedings of the USENIX 1985 Summer Conference, pp. 119-130, 1985.

[sun89] Sun Microsystems, NFS: Network File System Protocol Specification, Network Working Group Request For Comments (RFC) 1094, March 1989.

[sun95] Sun Microsystems, NFS Version 3 Protocol Specification, Network Working Group Request for Comments (RFC) 1813, June 1995.

[sun96a] Sun Microsystems, WebNFS Client Specification, Network Working Group Request for Comments (RFC) 2054, October 1996.

[sun96b] Sun Microsystems, WebNFS Server Specification, Network Working Group Request for Comments (RFC) 2055, October 1996.

[sun97] Sun Microsystems, WebNFS, April 1997.