Friday, August 5, 2011

file system based on a single file and loop device

Worked on a task to test performance of read/write on various file system options on my RHEL5 box:
  • native ext3
  • virtual ext3 based on a zero-filled image file
  • virtual ext3 based on a sparse image file
  • virtual ext2 based on a sparse image file
The virtual file system is basically based on a big file connected as a loop device. This tutorial about setting up disk quota based on virtual file system has more details. For example, this is the basic steps to set up a virtual ext3 file system based on a sparse file:

dd if=/dev/null of=/tmp/vfs/sparse.image bs=1M seek=100
mkfs -t ext3 -q /tmp/vfs/sparse.image -F
mkdir /tmp/quota
sudo mount -t ext3 -o rw,loop /tmp/vfs/full.image /tmp/quota

The experiment is quite preliminary: basically, I copy over files in different sizes (1, 5, 10, 25, 50MB) into the mounted file system directory or the native file system directory to test write latency, then read the copied files to test read latency. The read/write latency is averaged over 10 iterations.

A couple of quick points from the experiments:

  • read latency is similar for all four cases.
  • write latency for native ext3 is around half of the virtual ext3 based either on a sparse file or a zero-filled file.
  • write latency for native ext3 is roughly the same as virtual ext2, maybe because ext2 gets rid of the journaling overhead.
  • creating a virtual file system based on a sparse file has many advantages over a zero-filled file: the creation time is way much faster 6-8 order of magnitude for the file sizes we tried, the bigger the file, the bigger the difference; the sparse file does not occupy physical disk space and grows when content is actually written to disc.
  • virtual ext3 has spikes for write, sometimes as big as 80x the average write latency, not exactly what caused it.
This is final the performance graph for comparison. I am using the average number here, notice that the high average latency for write on virtual ext3 is caused by the spikes mentioned above.


After removing the spikes, using virtual ext3 based on a sparse file or zero-filled file creates around 2X the latency for native ext2 or ext2 based on a sparse file, as show in the second graph: