• NFSSTONE

Table of Contents

NFSSTONE

Please note that NFSSTONE has now been replaced by nhfsstone.

NFSSTONE is a benchmark aimed at network file systems. The file system being benchmarked is tested independent of the underlying network configuration and protocols, this allows a variety of file systems and network combinations to be benchmarks with a single product.

The results that NFSSTONE reports are based on clients requesting a number of file operation and recording the time that is took to complete all the benchmark operations. The results are an independent value called NFSSTONEs.

• == Alternative ==

  • In recent months Gelato@UNSW has ported nfsstone to ipbench. Ipbench allows multiple clients to synchronously direct a requested benchmark at one or more test targets, producing results on a controlling node. There are several advantages to this:

    • Synchronisation of the benchmark on start up and shutdown.
    • A controlling node that initiates the benchmark and collects the results, this removes the need for an individual to login to the client and target machines in order to run the benchmark.
    • Reduced network traffic and processes running on the clients and target, due to the ability to run the benchmark from a separate controlling machine.

    Modifications

    • In the process of porting nfsstone to ipbench, we made several changes to the benchmark these are:
      • Output an average and standard deviation(n-1) over all benchmark clients.

      • Allow the amount of work to be performed, (TOPDIRS, BOTDIRS), to be specified on the command line, with defaults set the original values.

      • Split the benchmark into several new routines inline with the ipbench interface.

    Note: We did not change was the number or order of file system operations that are performed by the original nfsstone benchmark.

Configuration

NFSSTONEs are the total number of file operations that are performed by the benchmark. These operations are tuneable and compile time through #define values in the source. The main factors for NFSSTONE are the total number of directories for a single run TOT_DIRS and the files per directory FILES_PER_DIR.

• TOT_DIRS: the sum of the values TOP_DIRS and BOT_DIRS:

  • TOP_DIRS: defines the number of times all tests are to be performed, and

  • BOT_DIRS: defines the number of times the set of write and read operations are performed for each TOP_DIRS.

• Other tuneable compile time options are:

  • FILE_CREATES: the number of times a file is created for each BOT_DIRS test.

  • NREAD_LINK:

  • BLOCKS_PER_FILE:

  • FILE_LOOKUPS:

  • BYTES_PER_BLOCK:

Compiling

• gcc nfsstone.c -o nfsstone

Running NFSSTONE

• ./nfsstone <test file system path> <lock file>

Assumptions

• Clients are run on a network file system.

• Treats the file system as a black box therefore the benchmark is independent of the underlying filesystem, network protocol and architecture, and Operating System(OS). If however you are using the later nhfsstone then you will need to have a NFS running since the benchmark inspects the NFS statistics.

Benefits

• NFSSTONE is a simple benchmarks that makes few assumptions, the main assumption is that the client is run on a network file system, this allows the standard file system calls (read, write, lookup and file status) to be used.
• The benchmark makes no assumption about the underlying file system (networked or not), network protocols and architecture, and the OS that is run on.

Problems

• Manual synchronisation of distributed clients is required for high end server benchmarks. That is, if the work load required by the server exceeds the maximum request rate of a single client, then multiple clients would be required to generate sufficient load. This was show in the tests where the authors of [1] used an under powered server with a higher powered client.

Results

• There are several configuration possibilities to consider when setting up the NFSSTONE benchmark:

  • The filesystem that backs the network file system exports, for instance exporting a NFS backed by an ext3 filesystem introduces a journal for the file system, this has a direct impact on results. The effect of a been seen in the comparison between ext3-sample and ext2-sample. With ext3 the benchmark ran 40 times longer compared to the ext2 run. The previous samples are not official results as I would like to run the ext3 test again to obtain extra NFS and lockmeter information.

Lock Meter

• Lockmeter is a patch that instruments the Linux kernel to allow monitoring of locks on an SMP kernel.

  • Andrew Morton maintains Lockmeter patches for some kernels, these can be found here.

  • Lockstat will be required to gather and extract locking information.