SMREmulator 1.0
ShingledMagneticRecordingEmulator

Shingled Magnetic Recording Emulator

Author:
Anand Suresh <anandsuresh@cmu.edu>

Introduction

The Shingled Magnetic Recording (SMR) Emulator is a user-space emulator closly modelled on the Seagate T13 Interface proposal. It is intended for use with studies to examine workloads that are most suited for Shingled Magnetic Recording technology. This document details the design decisions that have shaped the development of the SMR Emulator, along with detailed descriptions of its structure and interfaces. The structure of this document will be as follows:

Design
This section discusses the overall design of the emulator describing the layered architecture and interfaces between the layers.

Utilities
This section talks about the utility programs that have been developed as part of the emulator package. These programs allow for creation of new EDI files, and manipulation of data and metadata on the EDI files from the command line.

Design

An emulated SMR HDD is stored as a single file called an Emulated Disk Image (EDI) file. All data pertaining to the HDD including internal metadata is stored in the EDI file. The format of the file depends on the EDI version and the Emulator is intended to support multiple versions without having the need to recompile the source each time.

The Emulator is designed using a layered approach, as described below.

Todo:
Add Image here.

Emulator

At the top is the Emulator which interfaces with the external program (which in our case is a FUSE-based file system implementation). This layer provides support for operating upto 8 EDI files simultaneously. In other words, the external program can open upto 8 emulated disks to operate on them.

The limitation of 8 was an estimated worst-case upper bound on the number of simultaneous emulated disks that might be used with our experimentation. This can be changed by altering the value of the MAX_EDIS macro in emulator.h.

Emulator Interface

The Emulator interface consists of the following functions defined in emulator.h. These functions can be called by external programs to operate the emulated disk.

The following functions make up the Emulator interface:

Invocation Sequence

The fastest way to get up and running is to mimic the following sequence of function calls.

1. edi_init() Calling this function initializes the Emulator and prepares all necessary data structures.

2. edi_open() The next step is to open the EDI file. This can be done using edi_open function which accepts the path to the EDI file as its only input parameter. The function returns an integer, which can be used by the program as a file descriptor to the open EDI file, and passed to the emulator in all future calls.

3. edi_modesense() At this point, it is essential to know the details of the emulated disk that was openend; most importantly the block size of the EDI and the number of shingled bands it contains. This is where the edi_modesense() function comes into play.

4. edi_read() / edi_write() / edi_managebands() Now the emulator is ready for operation. The external program can now use any valid combination of calls to edi_read(), edi_write() and edi_managebands() to read and write data to the EDI and manage band metadata as required.

5. edi_close() Finally, when all operations have been performed, the EDI file should be closed with a call to edi_close().

Todo:
Document the Versioning Interface here.

Utilities

The emulation library comes with a set of utilities that allow for easy creation and management of Disk Images. Listed below are the utilities and their functions.

edicreate

This program will create a new blank disk image based on the version information and other options passed to the program. It can be invoked as follows:

edicreate -v <version> -s <block size> -c <band count> -b <band size> -f <filename>

Depending on the parameters selected, the program will create a new EDI file and initialize it for use.

Note that in the event the file specified already exists, the program will terminate with error. This is to ensure that existing disk images are not accidentally erased.

See also:
edicreate.c