Currently we have a prototype network-attached disk. It provides more functionality than block devices such as IDE disks or CD-ROMs. Designing and building a file system that takes advantage of these differences would be useful to us in testing and evaluating the prototype.

The project would consist of using a modified NFS server to do file system development without requiring kernel development. Initially the file system should be stored in a file on a normal file system before moving to using the network-attached-disk. There are libraries for communicating with the disk.

Special Resources: some familiarity with UNIX and a willingness to program in C. It would be useful to have a machine running Linux, but access to the SRG Linux machines would be needed in any case.

The network-attached disk described above is designed to support the provision of performance guarantees. One type of application which clearly needs these guarantees are applications stream media. Building a video player which uses the disk would provide us with a useful workload to test the disk, and an attractive demo to amaze potential funders.

The project would consist of designing a suitable layout for the video on disk, and implementing an MPEG video player for some operating system, such as Linux. It would be a very good idea to use freely available MPEG decoders, and concentrate on building a system that efficiently supports fast-forward, rewind and jumping to scenes, possibly also being able to degrade performance when it isn't possible to retrieve the video fast enough.

Communication with the disk is done through a simple C library, and initially it would be a very good idea to write a version of the library which used a file rather than the network-attached disk. This means that development can be done in a safe environment. The libraries only work on Linux, as they use various features on that operating system to send and receive packets from the disk.

Special Resources: The project is suitable for someone with some experience of C (or willingness to learn prior to the project), and someone who is not daunted by the task of learning other people's code. It would be useful to have access to a machine running Linux, but access to the group's Linux machines would also be required.

We have a plenty of disk space in the lab, but it is distributed amongst a large number of workstations. This leads to a few problems:

• It becomes hard to remember where you left a file since the naming scheme includes the workstation name as part of the file's name.
• Different disks have different properties: fast SCSI, attached to fast CPU, near some other workstation, backed up, striped, etc.

Currently, the name of the file implicitly encodes this information, and you cannot change the properties of the file without moving it. This leads to files which should be together actually being apart because some of them need to be backed up. Symbolic links go some way to solving this problem but it is not a transparent solution, and can be hard to maintain.

Another possible solution to this problem would be to add a naming layer on top of our already existing NFS infrastructure. This would separate a file's name from its properties. The mapping from (file name, properties) to underlying storage name should be computed by the system to select appropriate storage that satisfies the required properties. For example, it a file is marked with the property ``backed up,'' it should reside somewhere on backed up storage.

Possible extensions include doing distributed caching of the data, or (related to this) gradually migrating the data towards the consumers, thus optimising the data's location as time progresses.

There are many ways of implementing this: pretending to be an NFS server much like amd does, or as a completely new filesystem type over userfs or directly as a module. Masquerading as an NFS server is likely to be the simplest. Some scheme for representing the file's meta data will also be needed. CODA may be of some interest.

Special Resources: SRG Linux access

To conduct useful research into storage systems we need to have a good idea of what workload is placed on the systems we are trying to improve. Currently much work is done using disk-block access traces gathered from systems many years ago, there is very little knowledge of modern systems.

This is a project suitable for people experienced with Linux & C. It would consist of instrumenting a Linux kernel to produce traces at various levels of the I/O system: access to block devices above and below the block cache, and file system accesses. The tracing should be as unobtrusive as possible.

Special Resources: access to Linux machines, and a willingness to learn about the Linux kernel, for which there is little documentation.

Currently the performance observed by users of disks is affected greatly by where the data is placed on that disk. Towards the outside of the disk there are a greater number of sectors that pass under the head quickly, so higher throughput is observed, than on the inside of the disk. This project would consist of building a system which striped the data over two disks in such a way that near-to-average performance is observed across the entire disk.

Special Resources: access to a Linux machine with two, identical spare hard disks.

Contemporary filing systems map names to files by using a hierarchical lookup scheme built from nested directories. This allows a relatively efficient name resolution algorithm along with considerable flexibility for the user. Search paths or naming conventions may be used to prefer a given version of a file.

In many cases, however, users would prefer a scheme which allows them to retrieve or specify files based on queries, boolean expressions relating to meta-data such modification date, owner, type, keywords, etc. Such operations may return 0, 1, or many files.

This project will investigate suitable schemes for both on-disk and in-core data structures to support a query filing system (QFS). A prototype implementation will be developed at user-space level (most likely under Linux using the UserFS library). As a possible extension, information about queries could be used to provide "hints" to the buffer cache and prefetching scheme and so improve performance.

Special Resources: an account on the SRG Linux boxes; access to a free disk/partition.