ShingledFS 2.0
SMR-AwareFUSE-basedFileSystem
|
ShingledFS is a FUSE-based User-space File System that is designed to work with shingled/banded devices. In its present form, it operates with the Shingled Magnetic Recording (SMR) Emulator - a user-space emulator closly modeled on the Seagate T13 Interface proposal. This document details the design decisions that have shaped the development of ShingledFS along with detailed descriptions of its structure and interfaces.
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.
ShingledFS is designed to be operated as a single-threaded daemon that implements most of the common VFS functions used by applications to create and manage files in the file system.
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.
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:
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().
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.
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.