Build and Run SMRfs

How to build and run SMRfs?

The figure explains the structure of the code of SMRfs. start.sh file in smr-disks/src/test/local is the script that does the job of building and invoking the shingledfs process. On running start.sh it cleans and builds the code each time to ensure that any changes made since the last build are correctly incorporated. Several variables in start.sh determine where in the filesystem tree is SMRfs being executed. By default PATH_BASE (the directory inside which all other directories including the unshingled partition reside) is set to /tmp/smr. One can easily customize these paths, but in doing so, one must be careful about the necessary permissions of the customized path. The size of shingled disk is also a tunable parameter present in start.sh. Simply put, 3 numbers determine the size of the shingled partition - number of bytes per block, number of blocks per band and total number of bands. The multiplication of all the 3 numbers will be the size of the shingled disk (in bytes).

SMRfs can be run in several ways, all of which are explained below:

• ./start.sh - run SMRfs with emulator creating an image file, without logs and without FUSE in foreground
• ./start.sh log - run SMRfs with emulator creating an image file with creation of log files in /tmp, but without FUSE in foreground
• ./start.sh debug - run SMRfs with emulator creating an image file with creation of log files in /tmp and with FUSE in foreground mode
• ./start.sh raw - run SMRfs atop raw partition (with the partition being mapped to /dev/raw/raw1), but without FUSE in foreground
• ./start.sh raw-debug - run SMRfs atop raw partition (with the partition being mapped to /dev/raw/raw1) and with FUSE in foreground mode

SMRfs process can be cleanly terminated (including the unmounting of the tmpfs-based buffercache) by running stop.sh. In case paths in start.sh are updated, this scipt also must be updated to reflect the custom paths.

Why run SMRfs on RAW (unformatted) partition?

By default, the emulator on which SMRfs runs, creates an image file of the size specified in start.sh. That file is created on the underlying filesystem on which PATH_BASE resides. Therefore, any read / write operation that happens on SMRfs, in turn is reflected on the image file by the emulator. If one wants to measure / speak about performance of SMRfs, measuring seeks is crucial. If the underlying parition is not RAW, the seeks measured are those of the underlying filesystem, which might be different from what one can expect from the original hardware. To make more reliable statements about performance, it is essential that SMRfs is run on RAW disk partitions.

Following is the way to create / associate a raw device if SMRfs is to be run on a raw disk partition:

• modprobe raw - insert the raw module into the running kernel which in turn creates the /dev/raw folder and internal device nodes.
• sudo /dev/raw/raw1 /dev/sda<n> - maps /dev/raw/raw1 character device node to block device /dev/sda<n>. /dev/sda<n> is the partition that you're supposed to create by deleting /dev/sda4 (a default non-initialized partition of ~ 2TB) on a marmot instance and creating smaller partitions (if needed) for testing of SMRfs in comparison with other filesystems viz. Btrfs, Ext4 and Nilfs.

Btrfs-based unshingled partiton:

In the default mode of operation, SMRfs will create a directory called unshingled in the PATH_BASE variable set in start.sh. That directory by default is a part of the native filesystem present at that path. As SMRfs maintains almost all of its metadata as xattr of files, the choice of filesystem for mounting the unshingled directory is crucial. For example, on performing a kernel untar test, if the unshingled directory is kept on Ext4, the unshingled directory size is > 100 MB. If for the same test, if the underlying filesystem of the unshingled directory is Btrfs, the size is reduced to < 2 MB. This large difference is due to the fact that Btrfs tends to pack xattrs of all files in a single B-tree on disk, while Ext4 maintains each file's metadata separately (leading to the creation of at least 1 block per file's xattr).

Following are the ways to create a Btrfs-based unshingled partition:

• If you have a disk partition that you can spare, format it as Btrfs, mount it on a particular directory. Specify that directory as PATH_USHNG in start.sh.
• If you do not have a disk partition, dd approximately a 1 GB image. Associate that with a loopback device, say /dev/loop1. Format /dev/loop1 as Btrfs. Mount it on a particular directory. Specify that directory as PATH_USHNG in start.sh.

In either case it is advised that you take care to clean the unshingled partition as well (if needed) while performing multiple runs of SMRfs.