Lecture 38

Soft Updates Benchmarks

These benchmarks were performed on ``commodity PC systems equipped with a 300MHz Pentium II processor, 128MB of main memory, and two 4.5GB Quantum Viking disk drives (Fast SCSI-2, 7200 RPM, 8ms average seek for reads). One disk drive holds the root, home, and swap partitions, and the second drive is used for the file system under test. The operating system is FreeBSD 4.0, and all experiments are run with no other nonessential activity in the system.''

In these experiments, No Order corresponds to FFS without requiring synchronous metadata updates.

The following image shows the results (given as throughput in megabytes/second) of creating files of various sizes using Conventional FFS, No Order FFS, and Soft-Updates FFS. As expected, both Soft-Updates, and No Order outperform conventional FFS. Operations were performed on 25 runs each, yielding a coefficient of variation of less than 0.07.
The next image shows the results (in files/second) of deleting files of various sizes. In this case, the coefficients of variaton are below 0.1 with the single exception of the 4096 KB point, for which the coefficient of variation is 0.13.

Soft-updates outperforms No Order in this case because No Order actuall must delete the files in the foreground. The big No Order drop occurs at the 104 MByte boundary.
Several points of interest are the following:
- 64 KB (after which a file will require two contiguous data segments)
- 104 KB (after which a file will require and indirect data block)
- 1024 KB (after which all the data of a file cannot be stored in a single cylinder group)
The following image shows read performance (measured in MBytes/sec) as a function of file size. In this case the coefficients of variation are less than 0.04.
After files reach 96 KB, FFS uses a reallocation scheme to keep files contiguous. Delaying deallocations lets Soft Updates avoid placing indirect blocks in undesirable locations.
The final figure shows the number of disk write operations carried out during the file creation benchmark. Conventional FFS requires several more writes to create a file than either No Order or Soft Updates. The gap between the systems decreases partly because the number of files created decreased in the benchmark as the files got larger.
A file system with Soft Updates can be repaired using fsck in significantly less time than a conventional file system. In a conventional file system, fsck requires 5 seconds on an empty file system and 150 seconds on a 76% full file system. A Soft Updates file system fsck requires 0.35 seconds in either case.
Testing the repair performance of Soft Updates by halting a benchmark in process showed no errors, whereas the conventional file system required off-line assistance before being usable in 96% or attempts, and the No Order file system yielded unresolvable inconsistencies (a disk block appears in more than one file) in 30% of trials.
Soft Updates provide a 4-19% benefit in system throughput over a traditional logging file system (presumably due to extra I/O required to maintain the log).

WAFL (Write Anywhere File Layout)

This material drawn from Hitz, D., Lau, J., & Malcolm, M., File System Design for an NFS File Server Appliance, TR3002, Network Appliance, Inc.

WAFL is the file system used by Network Appliance, Inc., in their Network Attached Storage filer devices.
The goals of WAFL are:
- It should provide fast NFS service.
- It should support large file systems (tens of GB) that grow dynamically as disks are added.
- It should provide high performance while supporting RAID (Redundant Array of Independent Disks).
- It should restart quickly, even after an unclean shutdown due to power failure or system crash.
The most notable aspect of the WAFL file system is its support for snapshots. A snapshot is a read-only copy of the entire file system. In WAFL, snapshots can be created with no delay whatsoever. Up to 20 snapshots can be created and maintained on-line under a schedule specified by the system administrator.
The snapshot files for any given directory can be accessed by changing directory to its hidden .snapshots directory. The .snapshots directory contains all the various snapshot versions of that directory.
The fundamental design element that lets WAFL provide these snapshots at no apparent cost is that all metadata is stored in files. In particular, the inode file, free blockmap file, and inode-map file maintain three file system structures that are not normally kept in files. Because this information is kept in files, it can be placed anywhere on the disk and multiple metadata versions can be kept.
The following picture shows how all structures are maintained in files in WAFL. The only structure shown that needs to reside in a fixed position is the root inode.
Whenever a block is changed in WAFL, a new copy of the block gets written to disk. The old copy is maintained (so it can be present in a snapshot).
A snapshot can be taken simply by copying the root inode.
As you probably suspect, if a single block of any file is changed, its inode is changed, the directory containing its inode is changed, and so forth, and so on, all the way back to the root node. This seemingly endless ripple of changes can be effectively written to disk using a technique like that of Soft Updates.
WAFL can keep track of may different snapshot versions of a file by adding extra information into the free block map. In typical file system implementations, the block map contains only a single bit per block (marking whether or not the block is available). In WAFL, the block map includes a bit for each active snapshot.
To insure that a consistent version of the file system gets put in each snapshot and that no time is wasted, the following sequence of steps is followed when creating a snapshot:
1. Dirty blocks in the active file system are marked IN_SNAPSHOT and are write-locked. (They must not be modified.)
2. Disk space is allocated for all IN_SNAPSHOT blocks. Data for each IN_SNAPSHOT block is copied into the disk buffer. When a block reaches the buffer the IN_SNAPSHOT bit is cleared.
3. The block-map file is updated by copying the active file system bit to the new snapshot bit.
4. All IN_SNAPSHOT disk buffers are written. As soon as a buffer is flushed it is unlocked, thus requests to write that block can proceed.
5. A duplicate of the root inode is created to represent the new snapshot and the root's IN_SNAPSHOT bit is turned off. This must be done after all other IN_SNAPSHOT blocks are written or else we could have an inconsistent snapshot state.
In the case of filers like the NetApp device, the statistic of interest is NFS or CIFS response time. The following graph compares WAFL on a FAServer (now called a filer by NetApp) to a variety of other NFS servers. Most of these are Sun Microsystems machines, one of the primary targets of NetApps early installations.