Permalink
Browse files

revise related

  • Loading branch information...
1 parent 9258861 commit 5cd8d9eaa69386bc3e1c577ea690fe2c9627aae6 Ming committed Dec 15, 2012
Showing with 86 additions and 71 deletions.
  1. +12 −0 doc/references.bib
  2. +4 −2 doc/report/main.aux
  3. +30 −30 doc/report/main.blg
  4. BIN doc/report/main.dvi
  5. +6 −6 doc/report/main.log
  6. +34 −33 doc/report/related.tex
View
@@ -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",
+}
+
View
@@ -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}
View
@@ -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
View
Binary file not shown.
View
@@ -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).
View
@@ -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

0 comments on commit 5cd8d9e

Please sign in to comment.