revise related

doc/references.bib

@@ -513,3 +513,15 @@ @article{vldb_flashup
     publisher = {VLDB Endowment},
 }
 
+@ARTICLE{tos06zen,
+  AUTHOR =       "E. Zadok and R. Iyer and N. Joukov and G. Sivathanu and C.
+    P. Wright",
+  TITLE =        "On Incremental File System Development",
+  JOURNAL =      "ACM Transactions on Storage (TOS)",
+  YEAR =         "2006",
+  MONTH =        "May",
+  VOLUME =       "2",
+  NUMBER =       "2",
+  PAGES =        "161--196",
+}
+

doc/report/main.aux

@@ -67,6 +67,7 @@
 \citation{eurosys_hfs}
 \citation{conquest_tos}
 \citation{umbrellafs_gos}
+\citation{tos06zen}
 \citation{tablefs}
 \citation{socc11chisl}
 \citation{vldb_flashup}
@@ -124,5 +125,6 @@
 \bibcite{conquest_tos}{23}
 \bibcite{wikimedia-foundation}{24}
 \bibcite{wikipedia-web}{25}
-\bibcite{zhang2012multi}{26}
-\bibcite{eurosys_hfs}{27}
+\bibcite{tos06zen}{26}
+\bibcite{zhang2012multi}{27}
+\bibcite{eurosys_hfs}{28}

doc/report/main.blg

@@ -2,44 +2,44 @@ This is BibTeX, Version 0.99c (TeX Live 2009/Debian)
 The top-level auxiliary file: main.aux
 The style file: plain.bst
 Database file #1: ../references.bib
-You've used 27 entries,
+You've used 28 entries,
             2118 wiz_defined-function locations,
-            640 strings with 8387 characters,
-and the built_in function-call counts, 8100 in all, are:
-= -- 784
-> -- 375
+            645 strings with 8542 characters,
+and the built_in function-call counts, 8528 in all, are:
+= -- 825
+> -- 403
 < -- 6
-+ -- 157
-- -- 126
-* -- 511
-:= -- 1249
-add.period$ -- 78
-call.type$ -- 27
-change.case$ -- 154
++ -- 168
+- -- 136
+* -- 552
+:= -- 1322
+add.period$ -- 81
+call.type$ -- 28
+change.case$ -- 162
 chr.to.int$ -- 0
-cite$ -- 27
-duplicate$ -- 311
-empty$ -- 705
-format.name$ -- 126
-if$ -- 1764
+cite$ -- 28
+duplicate$ -- 322
+empty$ -- 732
+format.name$ -- 136
+if$ -- 1847
 int.to.chr$ -- 0
-int.to.str$ -- 27
-missing$ -- 14
-newline$ -- 129
-num.names$ -- 34
-pop$ -- 223
+int.to.str$ -- 28
+missing$ -- 15
+newline$ -- 134
+num.names$ -- 36
+pop$ -- 229
 preamble$ -- 1
-purify$ -- 126
+purify$ -- 133
 quote$ -- 0
-skip$ -- 235
+skip$ -- 242
 stack$ -- 0
-substring$ -- 373
-swap$ -- 67
+substring$ -- 403
+swap$ -- 68
 text.length$ -- 6
 text.prefix$ -- 0
 top$ -- 0
-type$ -- 108
+type$ -- 112
 warning$ -- 0
-while$ -- 57
-width$ -- 29
-write$ -- 271
+while$ -- 61
+width$ -- 30
+write$ -- 282

doc/report/main.log

@@ -1,4 +1,4 @@
-This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=latex 2012.8.26)  15 DEC 2012 02:13
+This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=latex 2012.8.26)  15 DEC 2012 16:25
 entering extended mode
  %&-line parsing enabled.
 **main.tex
@@ -605,12 +605,12 @@ Underfull \hbox (badness 10000) in paragraph at lines 151--153
 
 ) [9] (./main.aux) ) 
 Here is how much of TeX's memory you used:
- 11137 strings out of 495062
- 201886 string characters out of 1182644
- 249749 words of memory out of 3000000
- 14013 multiletter control sequences out of 15000+50000
+ 11138 strings out of 495062
+ 201896 string characters out of 1182644
+ 249754 words of memory out of 3000000
+ 14014 multiletter control sequences out of 15000+50000
  21689 words of font info for 66 fonts, out of 3000000 for 9000
  29 hyphenation exceptions out of 8191
  63i,11n,57p,435b,351s stack positions out of 5000i,500n,10000p,200000b,50000s
 
-Output written on main.dvi (9 pages, 63424 bytes).
+Output written on main.dvi (9 pages, 63796 bytes).

doc/report/related.tex

@@ -1,70 +1,71 @@
 \section{Related Work} 
 \label{sec:related} 
-Our work of optimizating performance of a key/value store using hybrid
-storage devices is related to (1) hybrid filesystems, (2) multi-tier
-storage, and (3) multi-level caching. 
+Our work of optimizing the performance of a key/value store using
+hybrid storage devices is related to (1) hybrid filesystems, (2)
+multi-tier storage, and (3) multi-level caching. 
 
 \paragraph{(1) Hybrid Filesystems}
 
 hFS~\cite{eurosys_hfs} is a hybrid filesystem which treats data
 differently based on their size and type. Metadata and small files are
-stored separately in a log partition like log-structured filesystem;
-data blocks of large regular files are stored in a partition in a
-FFS-like fashion. Similar to hFS, Conquest~\cite{conquest_tos} uses
-battery-backed RAM to hold metadata and small files. Only large files
-go to disk. Unlike hFS, UmbrellaFS~\cite{umbrellafs_gos} is a hybrid
-stackable filesystem sit bellow VFS but above general filesystems such
-as Ext2.  UmbrellaFS is able to use different devices including SSD.
-TableFS \cite{tablefs} uses NoSQL store for metadata and small files.
-However, its main objective is to improve the performance of a
-filesystem using NoSQL store.
+stored separately in a log partition in a log-structured filesystem
+manner; data blocks of large regular files are stored in a partition
+in a FFS-like fashion. Similar to hFS, Conquest~\cite{conquest_tos}
+also stores metadata and small files separately, but in battery-backed
+RAM.  Only large files go to disk. Unlike hFS,
+UmbrellaFS~\cite{umbrellafs_gos} is a hybrid stackable
+filesystem~\cite{tos06zen} sitting bellow VFS but above general
+filesystems such as Ext2.  UmbrellaFS is able to use different devices
+including SSD.  TableFS~\cite{tablefs} uses NoSQL store for metadata
+and small files.  However, its main objective is to improve the
+performance of a filesystem using NoSQL store.
 
 Whereas all of them integrate hybrid techniques into the filesystem
 layer, our system lies in the application layer which is above the
 filesystem layer. It optimizes the operations of an object store,
 which provides a different interface from the POSIX filesystem
 interface. This is an important difference because the filesystem
 interface lacks application level knowledge, which is very useful in
-optimizating application performance.
+optimizing application performance.
 
 \paragraph{(2) Multi-tier Storage}
 %
 GTSSL~\cite{socc11chisl} presents an efficient multi-tier key/value
 storage architecture, wherein Flash SSD is used for storing top layer
-SSTable above the disk. However, workload specific characters, such as
+SSTables above the disk. However, workload specific characters, such as
 size-tiered property are not exploited. As a follow-up research of
 GTSSL, MRIS can integrate nicely with GTSSL. Koltsidas and
-Viglas~\cite{vldb_flashup} improved the performance of database by
-using both Flash and disk drives. They decided either Flash or disk
-should be used in the database buffer manager, which is also unware of
-knowledge such as object size. Moreover, their study was based an old
-model, which considers Flash write to be 10 times slower than disk
-write. This is no longer true, as we see from
-Subsection~\ref{sec:drives}, thanks to the development of hardware and
+Viglas~\cite{vldb_flashup} improved the performance of database
+systems by using both Flash and disk drives. They decided either Flash
+or disk should be used in the database buffer manager, which is also
+unaware of knowledge such as object size. Moreover, their study was
+based an old model, which considers Flash write to be 10 times slower
+than disk write. This is no longer true, as we can see from
+Figure~\ref{fig:drivewrite}, thanks to the development of hardware and
 software used in Flash SSD. FAWN~\cite{sosp09fawn} is a distributed
 multi-tier key/value store. They used a two-tier architecture of RAM
-and Flash SSD, but not Flash SSD and HDD. Most of their strategies are
-not applicable here because of the large performance disparity
-between RAM and disk. Furthermore, their design for energy saving is
-orthognal to our work.
+and Flash SSD, but not Flash SSD and HDD. Their architecture is not
+applicable here because of the large performance disparity between RAM
+and disk. Furthermore, their design for energy saving is orthogonal to
+our work.
 
 \paragraph{(3) Multi-level Caching}
 %
-Storage class memory such as Flash fills the gap between DRAM and HDD
-in termns of cost, capacity and performance. It can be considered
-either as backup for DRAM in the virtual memory layer or cache for HDD
+Storage class memory such as Flash fills the gap between RAM and HDD
+in terms of cost, capacity and performance. It can be considered
+either as backup for RAM in the virtual memory layer or cache for HDD
 in the block layer. Zhang et al.~\cite{zhang2012multi} and Saxena et
-al.~\cite{flashvm} consider using Flash as backup of DRAM for paging,
+al.~\cite{flashvm} consider using Flash as backup of RAM for paging,
 whereas FlashTier~\cite{eurosys_12_flashtier},
 FlashCache~\cite{flashcache} and Bcache~\cite{bcache} use Flash as
 block level cache. Our work resides in neither the virtual memory nor
 the block layer. It is agnostic to all the above-mentioned techniques.
 Moreover, both Zhang et. al.~\cite{zhang2012multi} and Saxena et
-al.~\cite{flashvm} tried to reduce cost by replacing a portion of DRAM
+al.~\cite{flashvm} tried to reduce cost by replacing a portion of RAM
 with SSD without cost penalty. This objective does not conflict with
-design of MRIS, however, it is not in our design concerns.
+the design of MRIS, however, it is not in our design concerns.
 
-Forney et al. \cite{Forney2002fast} proposed storage aware caching for
+Forney et al.~\cite{Forney2002fast} proposed storage aware caching for
 heterogeneous storage systems. They made memory cache aware of the
 different replacement costs and partitioned the cache for different
 storage devices.  However, their study is set in a different context