Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

finish background flash ssd part of report

  • Loading branch information...
commit 354e507c678911e21a8561e87d71c46fcbfd4058 1 parent 8d70b27
Ming authored
View
12 doc/references.bib
@@ -255,12 +255,24 @@ @inproceedings{kvworkload_sigmetrics
workload modeling},
}
+@MISC{ssdanatomy,
+ TITLE = "{Anatomy of SSDs}",
+ NOTE = "\url{http://www.linux-mag.com/id/7590/}",
+ KEY = "SSD"
+}
+
@MISC{flashcache,
TITLE = "{A Write Back Block Cache for Linux}",
NOTE = "\url{https://github.com/facebook/flashcache/}",
KEY = "Flashcache"
}
+@MISC{flashwiki,
+ TITLE = "{Flash Memory}",
+ NOTE = "\url{http://en.wikipedia.org/wiki/Flash_memory}",
+ KEY = "Flash"
+}
+
@MISC{bcache,
TITLE = "{A Linux kernel block layer cache}",
NOTE = "\url{http://bcache.evilpiepirate.org/}",
View
208 doc/report/bg.tex
@@ -1,78 +1,170 @@
\section{Background}
-\label{bg}
+\label{sec:bg}
+
+MRIS is a key/value store designed for multi-resolution image
+workloads using a multi-tier architecture consisting of Flash SSD and
+magnetic HDD.
+
+\subsection{Flash SSD}
+Flash is a type of non-volatile memory. There are two main types of
+flash memory, which are named after the NAND and NOR logic
+gates~\cite{flashwiki}. NAND is the more popular one used in
+SSDs~\cite{ssdanatomy}. NAND flash chip is able to trap electrons
+between its gates. The absence of electrons corresponds to a logical
+0. Otherwise, it corresponds to a logical 1. NAND can be furthered
+divided into SLC and MLC by the number of bits can be represented in a
+cell.
+
+NAND Flash has asymmetric read and write performance. Read is fast and
+takes roughly 50$mu$s for a MLC~\cite{ssdanatomy}. Write is 10-20
+times slower than read. However, write is complicated in the sense
+that bits cannot be simply overwritten. Before writes, a block has to
+undergo an erase procedure which is 2-3 order of magnitude slower than
+read. Moveroever, NAND Flash cell can endure only limit cycles of
+erasing. Therefore, Flash chips are often used for storage in the form
+of SSD, which also contains internal controller, processor and RAM.
+Algorithms including log-structured writing, wear-leveling, and
+garbage collection are implemented inside SSD to make Flash writes
+faster and endures longer.
+
+\subsection{Key/Value Store}
+We implemented MRIS using LevelDB~\cite{leveldb-web}, an open source
+key/value database engine developed by Google. LevelDB is
+log-structured and organizes data into Sorted String Table (SSTable).
+SSTable, introduced in Bigtable~\cite{chang06osdi}, is an immutable
+data structure containing a sequence of key/value pairs sorted by the
+key as shown in Figure~\ref{fig:sstable}. Besides key and value, there
+might be optional fields such as CRC, compression type etc. SSTable
+are mostly saved as files and each of them can contains data
+structures, such as bloomfilter, to facilitate key lookup. SSTable
+have counterpart in the memory called Memtable. The key/value pairs in
+Memtable are often kept in data structures easy for insert and lookup
+such as red/black tree and skiplist.
+
+LevelDB, as well as most other key/value engines, use Log-Structured
+Merge Trees (LSM)~\cite{lsm} for internal storage. When key/value
+pairs are first added, they are inserted into Memtable. Once the size
+of the Memtable growes beyond a certain threshold, the whole Memtable
+is flushed out into a SSTable, and a new Memtable is created for
+insertion. When key/value pairs get changed, the new pairs are
+inserted without modifying the old pairs. When a key/value pair is
+deleted, a marker of the deletion is inserted by setting a flag inside
+the key called \texttt{KeyType}. This way key/value can provide large
+insertion throughput because data is written out using sequential
+I/Os, which have good performance on Hard Disk Drives (HDD).
+
+\begin{figure}[t]
+\begin{centering}
+\epsfig{file=figures/sstable.eps,width=1.00\linewidth}
+\caption{SSTable}
+\label{fig:sstable}
+\end{centering}
+\end{figure}
+
+\begin{figure}[t]
+\begin{centering}
+\epsfig{file=figures/leveldb-compact.eps,width=1.00\linewidth}
+\caption{LevelDB Compaction}
+\label{fig:compact}
+\end{centering}
+\end{figure}
+
+To serve a key lookup, Memtable is queried firstly. If not found in
+Memtable, the SSTables are queried in reverse chronological order. A
+naive implementation of such a lookup can be very slow because the
+whole database need be read and checked in the worst case. To make
+lookup fast, SSTable are organized into several layers with the size
+of each table increasing from the top layer to the bottom. Background
+jobs are launched periodically to sort and merge small SSTables into
+larger ones in the next layer. This is called compaction. Deleted
+pairs are also removed during compaction. Then a lookup iterates the
+SSTables layer by layer and returns once the key is found. Because
+SSTables are sorted by key, it enables fast lookup algorithm like
+binary search. There is also index for SSTables tells the key range
+covered by a particular SSTable so that it suffice just checking the
+SSTables whose key ranges cover the interested key. Inside each
+SSTable, we can have a bloomfilter to filter negative key lookup and a
+secondary index for faster search.
+
+In LevelDB, there are two Memtables, once one is filled, the other one
+is used for further insertion. The filled one is flushed into a
+Memtable in background. Its compaction procedure is illustrated in
+Figure~\ref{fig:compact}. One SSTable (a) at layer $n$ is merged with
+the SSTables at layer $n+1$ that have overlapping keys with (a) into
+new SSTables at layer $n+1$.
+
+%Background...
+
+%Typical length: 0 pages to 1.0.
+
+%Background and Related Work can be similar.
+%Most citations will be in this section.
+
+%1. Describe past work and criticize it, fairly. Use citations
+ %to JUSTIFY your criticism! Problem: hard to compare to YOUR
+ %work, b/c you've not yet described your work in enough
+ %detail. Solution: move this text to Related Work at end of
+ %paper.
+
+%2. Describe in some detail, background material necessary to
+ %understand the rest of the paper. Doesn't happen often,
+ %esp. if you've covered it in Intro.
+
+%Example, submit a paper to a storage conference: reviewers are
+%experts in storage. Don't need to tell them about basic disk
+%operation. But if your paper, say, is an improvement over an
+%already-advanced data structure (eg., COLA), then it'd make
+%sense to describe basic COLA algorithms in some detail.
+
+%Important: open the bg section with some "intro" text to tell
+%reader what to expect (so experienced readers can skip it).
+
+%If your bg material is too short, can fold it into opening of
+%'design' section.
+
+
+%\textbf{notes about picking a project}
+
+%Put every possible related citation you can! (esp. if conf.
+%doesn't count citations towards page size).
+
+%Literature survey:
+%- CiteSeer
-Background...
+%- Google Scholar
-Typical length: 0 pages to 1.0.
+%- libraries
-Background and Related Work can be similar.
-Most citations will be in this section.
+%1. find a few relates paper
-1. Describe past work and criticize it, fairly. Use citations
- to JUSTIFY your criticism! Problem: hard to compare to YOUR
- work, b/c you've not yet described your work in enough
- detail. Solution: move this text to Related Work at end of
- paper.
+%2. skim papers to find relevance
-2. Describe in some detail, background material necessary to
- understand the rest of the paper. Doesn't happen often,
- esp. if you've covered it in Intro.
+%3. search for add'l related papers in Biblio.
-Example, submit a paper to a storage conference: reviewers are
-experts in storage. Don't need to tell them about basic disk
-operation. But if your paper, say, is an improvement over an
-already-advanced data structure (eg., COLA), then it'd make
-sense to describe basic COLA algorithms in some detail.
+%4. reverse citation: use srch engines, to find
+ %newer papers that cite the paper you like.
-Important: open the bg section with some "intro" text to tell
-reader what to expect (so experienced readers can skip it).
+%5. "stop" when reach transitive closure
-If your bg material is too short, can fold it into opening of
-'design' section.
+%- then go off and read it.
+%- think about "how can I improve" and "what was so
+ %good about that paper".
-\textbf{notes about picking a project}
+%- check future work for project ideas.
-Put every possible related citation you can! (esp. if conf.
-doesn't count citations towards page size).
+%- go to talks \& conferences
-Literature survey:
-- CiteSeer
+%Pick an idea:
-- Google Scholar
+%- novelty vs. incremental (how big of an increment?)
-- libraries
+%- idea vs. practical implications
+ %(implemented? released? in use as OSS or commercial?)
-1. find a few relates paper
+%- where to submit? good fit and match for quality.
-2. skim papers to find relevance
-
-3. search for add'l related papers in Biblio.
-
-4. reverse citation: use srch engines, to find
- newer papers that cite the paper you like.
-
-5. "stop" when reach transitive closure
-
-- then go off and read it.
-
-- think about "how can I improve" and "what was so
- good about that paper".
-
-- check future work for project ideas.
-
-- go to talks \& conferences
-
-Pick an idea:
-
-- novelty vs. incremental (how big of an increment?)
-
-- idea vs. practical implications
- (implemented? released? in use as OSS or commercial?)
-
-- where to submit? good fit and match for quality.
-
-- look at schedule of conferences: due dates \& result dates.
+%- look at schedule of conferences: due dates \& result dates.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% For Emacs:
View
10 doc/report/conclusion.tex
@@ -9,11 +9,11 @@ \section{Conclusions}
of an emulated Facebook image workload by 3.73$\times$.
\paragraph{Future Work}
-We plan to study the model of multi-tier key/value considering cost,
-characteristics of different drives, as well as more workload specific
-features besides the ratio of read small and large objects. More
-threads will be used in benchmark to exploit better parallelism in
-Flash SSD.
+We plan to further study the model of multi-tier key/value considering
+cost, characteristics of different drives, as well as more workload
+specific features besides the ratio of read small and large objects.
+More threads will be used in benchmark to exploit better parallelism
+in Flash SSD.
\paragraph{Acknowledgement}
The author would like to thank Vasily Tarasov and Mike Ferdman for
View
32 doc/report/eval.tex
@@ -1,13 +1,14 @@
\section{Evaluation} \label{sec:eval}
We have evaluated our system on a 64-bit Dell server with 1GB memory
-and a one-core XXX CPU. The OS, a Ubuntu server 8.04 with kernel
-version 3.2.9, is installed on a Maxtor 7L250S0 3.5-inch SATA HDD. We
-used the same but another SATA HDD and one Flash based SSD for MRIS
-store. The HDD is also a Maxtor 7L250S0 with a capacity of 250GB and a
-rotational speed of 7200 rpm. The SSD is an Intel SSDSA2CW300G3
-2.5-inch with 300G capacity. The code and benchmark results are
-publicly available at https://github.com/brianchenming/mris.
+and a one-core Intel(R) Xeon(TM) CPU 2.80GH CPU. The OS, a Ubuntu
+server 8.04 with kernel version 3.2.9, is installed on a Maxtor
+7L250S0 3.5-inch SATA HDD. We used the same but another SATA HDD and
+one Flash based SSD for MRIS store. The HDD is also a Maxtor 7L250S0
+with a capacity of 250GB and a rotational speed of 7200 rpm. The SSD
+is an Intel SSDSA2CW300G3 2.5-inch with 300G capacity. The code and
+benchmark results are publicly available at
+https://github.com/brianchenming/mris.
\subsection{Measure drives}
\label{sec:drives}
@@ -102,12 +103,13 @@ \subsection{Wikipedia Image Workload}
$(4, 64]$ KB are most popular. They sum to 81.58\% of the total number
of image requests. Moreover, 94.57\% of the requests are for images
smaller than or equal to 128KB. Despite the fact that small images
-(<=128KB) are the absolute majority in term of request numbers, the
-traffic (size$\times$frequency) introduced by them is just 2.96\% of
-the total. Although not all the requests make their way to the storage
-layer because of memory cache (such as Memcached~\cite{memcached}).
-This salient size-tiered property of requests still makes size-tiered
-storage a close match for multi-resolution image workloads.
+(smaller than 128KB) are the absolute majority in term of request
+numbers, the traffic (size$\times$frequency) introduced by them is
+just 2.96\% of the total. Although not all the requests make their way
+to the storage layer because of memory cache (such as
+Memcached~\cite{memcached}). This salient size-tiered property of
+requests still makes size-tiered storage a close match for
+multi-resolution image workloads.
\subsection{MRIS Write}
@@ -272,8 +274,8 @@ \subsection{MRIS Read}
1000000 \frac{ratio + 1}{t_{SH} * ratio + t_{LH}}
\end{equation}
-By linear regression, we obtained the estimation of the variables
-(shown in Table~\ref{tbl:variable}) from our benchmark data.
+Using linear regression, we estimated the values of the variables
+(also shown in Table~\ref{tbl:variable}) from our benchmark data.
Approxmiately, the ops/sec of Hybrid can be expressed in
(\ref{eqn:hybridops}).
View
80 doc/report/implementation.tex
@@ -1,70 +1,6 @@
-\section{Implementation}
+\section{Design and Implementation}
\label{sec:implementation}
-\begin{figure}[t]
-\begin{centering}
-\epsfig{file=figures/sstable.eps,width=1.00\linewidth}
-\caption{SSTable}
-\label{fig:sstable}
-\end{centering}
-\end{figure}
-
-\begin{figure}[t]
-\begin{centering}
-\epsfig{file=figures/leveldb-compact.eps,width=1.00\linewidth}
-\caption{LevelDB Compaction}
-\label{fig:compact}
-\end{centering}
-\end{figure}
-
-We implemented MRIS using LevelDB~\cite{leveldb-web}, an open source
-key/value database engine developed by Google. LevelDB is
-log-structured and organizes data into Sorted String Table (SSTable).
-SSTable, introduced in Bigtable~\cite{chang06osdi}, is an immutable
-data structure containing a sequence of key/value pairs sorted by the
-key as shown in Figure~\ref{fig:sstable}. Besides key and value, there
-might be optional fields such as CRC, compression type etc. SSTable
-are mostly saved as files and each of them can contains data
-structures, such as bloomfilter, to facilitate key lookup. SSTable
-have counterpart in the memory called Memtable. The key/value pairs in
-Memtable are often kept in data structures easy for insert and lookup
-such as red/black tree and skiplist.
-
-LevelDB, as well as most other key/value engines, use Log-Structured
-Merge Trees (LSM)~\cite{lsm} for internal storage. When key/value
-pairs are first added, they are inserted into Memtable. Once the size
-of the Memtable growes beyond a certain threshold, the whole Memtable
-is flushed out into a SSTable, and a new Memtable is created for
-insertion. When key/value pairs get changed, the new pairs are
-inserted without modifying the old pairs. When a key/value pair is
-deleted, a marker of the deletion is inserted by setting a flag inside
-the key called \texttt{KeyType}. This way key/value can provide large
-insertion throughput because data is written out using sequential
-I/Os, which have good performance on Hard Disk Drives (HDD).
-
-To serve a key lookup, Memtable is queried firstly. If not found in
-Memtable, the SSTables are queried in reverse chronological order. A
-naive implementation of such a lookup can be very slow because the
-whole database need be read and checked in the worst case. To make
-lookup fast, SSTable are organized into several layers with the size
-of each table increasing from the top layer to the bottom. Background
-jobs are launched periodically to sort and merge small SSTables into
-larger ones in the next layer. This is called compaction. Deleted
-pairs are also removed during compaction. Then a lookup iterates the
-SSTables layer by layer and returns once the key is found. Because
-SSTables are sorted by key, it enables fast lookup algorithm like
-binary search. There is also index for SSTables tells the key range
-covered by a particular SSTable so that it suffice just checking the
-SSTables whose key ranges cover the interested key. Inside each
-SSTable, we can have a bloomfilter to filter negative key lookup and a
-secondary index for faster search.
-
-In LevelDB, there are two Memtables, once one is filled, the other one
-is used for further insertion. The filled one is flushed into a
-Memtable in background. Its compaction procedure is illustrated in
-Figure~\ref{fig:compact}. One SSTable (a) at layer $n$ is merged with
-the SSTables at layer $n+1$ that have overlapping keys with (a) into
-new SSTables at layer $n+1$.
A drawback of compaction is that pairs are read and written multiple
times when they are gradually merged from the top layer to the bottom.
@@ -126,13 +62,13 @@ \section{Implementation}
\end{centering}
\end{figure}
-A key/value is considered to be large and will be saved in LargeSpace
-when its value size is larger than a configurable threshold, named
-SizeThreshold. SizeThreshold provides a simple but effective knob to
-tradeoff between cost and performance when LargeSpace and SSTable are
-stored in different places. We plan to use more sophisticated
-algorithm to determine where to place a certain pair considering not
-only size but also hotness and access pattern.
+A large key/value pair will be saved in LargeSpace when its value size
+is larger than a configurable threshold, named SizeThreshold.
+SizeThreshold provides a simple but effective knob to tradeoff between
+cost and performance when LargeSpace and SSTable are stored in
+different places. We plan to use more sophisticated algorithm to
+determine where to place a certain pair considering not only size but
+also hotness and access pattern.
%Insertion of MRIS is illustruated in Figure~\ref{fig:mrisinsert}.
When key/value pairs are firstly inserted into Memtable, they are
View
6 doc/report/intro.tex
@@ -60,8 +60,10 @@ \section{Introduction}
%}
%\end{verbatim}
-The rest of the paper is organized as follows. Section
-\ref{sec:implementation} describe our design and implementation.
+The rest of the paper is organized as follows. Section \ref{sec:bg}
+presents the background of Flash SSD, multi-resolution images, and
+key/value store. Section \ref{sec:implementation} describe our design
+and implementation.
%Section \ref{sec:trace} presents the study Wikipedia's image requests
%and showes the size-tiered property in its workloads.
We evaluate the performance of our system in Section \ref{sec:eval}.
View
119 doc/report/main.aux
@@ -2,64 +2,67 @@
\citation{evans2002study}
\citation{kvworkload_sigmetrics}
\citation{kvworkload_sigmetrics}
-\citation{leveldb-web}
-\citation{chang06osdi}
+\citation{flashwiki}
+\citation{ssdanatomy}
\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction}{1}}
\newlabel{intro}{{1}{1}}
-\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces SSTable}}{1}}
-\newlabel{fig:sstable}{{1}{1}}
-\@writefile{toc}{\contentsline {section}{\numberline {2}Implementation}{1}}
-\newlabel{sec:implementation}{{2}{1}}
+\@writefile{toc}{\contentsline {section}{\numberline {2}Background}{1}}
+\newlabel{sec:bg}{{2}{1}}
+\citation{ssdanatomy}
+\citation{leveldb-web}
+\citation{chang06osdi}
\citation{lsm}
\citation{level_lifetime}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}Flash SSD}{2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.2}Key/Value Store}{2}}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces SSTable}}{2}}
+\newlabel{fig:sstable}{{1}{2}}
\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces LevelDB Compaction}}{2}}
\newlabel{fig:compact}{{2}{2}}
-\@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces Large Space}}{2}}
-\newlabel{fig:space}{{3}{2}}
+\@writefile{toc}{\contentsline {section}{\numberline {3}Design and Implementation}{2}}
+\newlabel{sec:implementation}{{3}{2}}
\citation{filebench-web}
+\@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces Large Space}}{3}}
+\newlabel{fig:space}{{3}{3}}
\@writefile{lof}{\contentsline {figure}{\numberline {4}{\ignorespaces MRIS Insertion.}}{3}}
\newlabel{fig:mrisinsert}{{4}{3}}
-\@writefile{toc}{\contentsline {section}{\numberline {3}Evaluation}{3}}
-\newlabel{sec:eval}{{3}{3}}
-\@writefile{lof}{\contentsline {figure}{\numberline {5}{\ignorespaces Read performance of SSD and HDD}}{3}}
-\newlabel{fig:driveread}{{5}{3}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.1}Measure drives}{3}}
-\newlabel{sec:drives}{{3.1}{3}}
+\@writefile{toc}{\contentsline {section}{\numberline {4}Evaluation}{3}}
+\newlabel{sec:eval}{{4}{3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.1}Measure drives}{3}}
+\newlabel{sec:drives}{{4.1}{3}}
\citation{wikipedia-web}
\citation{wikimedia-foundation}
\citation{memcached}
\citation{beaver2010finding}
+\@writefile{lof}{\contentsline {figure}{\numberline {5}{\ignorespaces Read performance of SSD and HDD}}{4}}
+\newlabel{fig:driveread}{{5}{4}}
\@writefile{lof}{\contentsline {figure}{\numberline {6}{\ignorespaces Write performance of SSD and HDD}}{4}}
\newlabel{fig:drivewrite}{{6}{4}}
\@writefile{lof}{\contentsline {figure}{\numberline {7}{\ignorespaces Image Requests to Wikipedia of January 2012}}{4}}
\newlabel{fig:wikiimage}{{7}{4}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.2}Wikipedia Image Workload}{4}}
-\@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces Setups For Benchmarking. The three setups differ in the places objects are stored.}}{4}}
-\newlabel{tbl:setups}{{1}{4}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.3}MRIS Write}{4}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.2}Wikipedia Image Workload}{4}}
\citation{beaver2010finding}
+\@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces Setups For Benchmarking. The three setups differ in the places objects are stored.}}{5}}
+\newlabel{tbl:setups}{{1}{5}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.3}MRIS Write}{5}}
\@writefile{lof}{\contentsline {figure}{\numberline {8}{\ignorespaces Write performance of MRIS.}}{5}}
\newlabel{fig:mriswrite}{{8}{5}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.4}MRIS Read}{5}}
-\@writefile{lof}{\contentsline {figure}{\numberline {9}{\ignorespaces MRIS Read Performance (ops/sec). Each operation represents a read of an image.}}{5}}
-\newlabel{fig:mrisopssec}{{9}{5}}
-\@writefile{lot}{\contentsline {table}{\numberline {2}{\ignorespaces Speedup of SSD and Hybrid over SATA (ops/sec).}}{5}}
-\newlabel{tbl:speedup}{{2}{5}}
-\newlabel{eqn:ssdops}{{1}{5}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.4}MRIS Read}{5}}
+\@writefile{lof}{\contentsline {figure}{\numberline {9}{\ignorespaces MRIS Read Performance (ops/sec). Each operation represents a read of an image.}}{6}}
+\newlabel{fig:mrisopssec}{{9}{6}}
+\@writefile{lot}{\contentsline {table}{\numberline {2}{\ignorespaces Speedup of SSD and Hybrid over SATA (ops/sec).}}{6}}
+\newlabel{tbl:speedup}{{2}{6}}
\@writefile{lot}{\contentsline {table}{\numberline {3}{\ignorespaces Costs of read operations in time ($\mu $s). For instance, $t_{SF}$ is the time of reading a Small image from the Flash SSD.}}{6}}
\newlabel{tbl:variable}{{3}{6}}
-\@writefile{lof}{\contentsline {figure}{\numberline {10}{\ignorespaces Modeled and benchmarked performance (ops/sec).}}{6}}
-\newlabel{fig:opspred}{{10}{6}}
+\newlabel{eqn:ssdops}{{1}{6}}
\newlabel{eqn:sataops}{{2}{6}}
\newlabel{eqn:hybridops}{{3}{6}}
-\newlabel{eqn:opsize}{{4}{6}}
-\newlabel{eqn:hybridthput}{{5}{6}}
+\@writefile{lof}{\contentsline {figure}{\numberline {10}{\ignorespaces Modeled and benchmarked performance (ops/sec).}}{6}}
+\newlabel{fig:opspred}{{10}{6}}
\@writefile{lof}{\contentsline {figure}{\numberline {11}{\ignorespaces MRIS Read Performance (mb/sec).}}{6}}
\newlabel{fig:mrismbsec}{{11}{6}}
-\@writefile{lof}{\contentsline {figure}{\numberline {12}{\ignorespaces Predicted and benchmarked read performance (mb/sec).}}{6}}
-\newlabel{fig:thputpred}{{12}{6}}
-\@writefile{lot}{\contentsline {table}{\numberline {4}{\ignorespaces Speedup of SSD and Hybrid over SATA (mb/sec).}}{6}}
-\newlabel{tbl:spdupmb}{{4}{6}}
+\newlabel{eqn:opsize}{{4}{6}}
+\newlabel{eqn:hybridthput}{{5}{6}}
\citation{eurosys_hfs}
\citation{conquest_tos}
\citation{umbrellafs_gos}
@@ -74,17 +77,18 @@
\citation{bcache}
\citation{zhang2012multi}
\citation{flashvm}
-\citation{Forney2002fast}
+\@writefile{lof}{\contentsline {figure}{\numberline {12}{\ignorespaces Predicted and benchmarked read performance (mb/sec).}}{7}}
+\newlabel{fig:thputpred}{{12}{7}}
+\@writefile{lot}{\contentsline {table}{\numberline {4}{\ignorespaces Speedup of SSD and Hybrid over SATA (mb/sec).}}{7}}
+\newlabel{tbl:spdupmb}{{4}{7}}
\@writefile{lof}{\contentsline {figure}{\numberline {13}{\ignorespaces MRIS Read Performance (mb/sec) by iostat}}{7}}
\newlabel{fig:mrisiostat}{{13}{7}}
-\@writefile{toc}{\contentsline {section}{\numberline {4}Related Work}{7}}
-\newlabel{sec:related}{{4}{7}}
+\@writefile{toc}{\contentsline {section}{\numberline {5}Related Work}{7}}
+\newlabel{sec:related}{{5}{7}}
\@writefile{toc}{\contentsline {paragraph}{(1) Hybrid Filesystems.}{7}}
\@writefile{toc}{\contentsline {paragraph}{(2) Multi-tier Storage.}{7}}
\@writefile{toc}{\contentsline {paragraph}{(3) Multi-level Caching.}{7}}
-\@writefile{toc}{\contentsline {section}{\numberline {5}Conclusions}{7}}
-\newlabel{sec:conc}{{5}{7}}
-\@writefile{toc}{\contentsline {paragraph}{Future Work.}{7}}
+\citation{Forney2002fast}
\bibstyle{plain}
\bibdata{../references}
\bibcite{sosp09fawn}{1}
@@ -94,21 +98,26 @@
\bibcite{chang06osdi}{5}
\bibcite{evans2002study}{6}
\bibcite{filebench-web}{7}
-\bibcite{flashcache}{8}
-\bibcite{Forney2002fast}{9}
-\bibcite{umbrellafs_gos}{10}
-\bibcite{vldb_flashup}{11}
-\bibcite{leveldb-web}{12}
-\bibcite{memcached}{13}
-\bibcite{lsm}{14}
-\bibcite{tablefs}{15}
-\bibcite{flashvm}{16}
-\bibcite{eurosys_12_flashtier}{17}
-\bibcite{level_lifetime}{18}
-\bibcite{socc11chisl}{19}
-\bibcite{conquest_tos}{20}
-\bibcite{wikimedia-foundation}{21}
-\bibcite{wikipedia-web}{22}
-\bibcite{zhang2012multi}{23}
-\bibcite{eurosys_hfs}{24}
+\bibcite{flashwiki}{8}
+\bibcite{flashcache}{9}
+\bibcite{Forney2002fast}{10}
+\bibcite{umbrellafs_gos}{11}
+\bibcite{vldb_flashup}{12}
+\bibcite{leveldb-web}{13}
+\bibcite{memcached}{14}
+\bibcite{lsm}{15}
+\bibcite{tablefs}{16}
+\bibcite{flashvm}{17}
+\bibcite{eurosys_12_flashtier}{18}
+\@writefile{toc}{\contentsline {section}{\numberline {6}Conclusions}{8}}
+\newlabel{sec:conc}{{6}{8}}
+\@writefile{toc}{\contentsline {paragraph}{Future Work.}{8}}
\@writefile{toc}{\contentsline {paragraph}{Acknowledgement.}{8}}
+\bibcite{level_lifetime}{19}
+\bibcite{socc11chisl}{20}
+\bibcite{ssdanatomy}{21}
+\bibcite{conquest_tos}{22}
+\bibcite{wikimedia-foundation}{23}
+\bibcite{wikipedia-web}{24}
+\bibcite{zhang2012multi}{25}
+\bibcite{eurosys_hfs}{26}
View
50 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 24 entries,
+You've used 26 entries,
2118 wiz_defined-function locations,
- 628 strings with 8096 characters,
-and the built_in function-call counts, 7632 in all, are:
-= -- 742
-> -- 372
+ 636 strings with 8240 characters,
+and the built_in function-call counts, 7944 in all, are:
+= -- 770
+> -- 374
< -- 6
-+ -- 154
++ -- 156
- -- 126
-* -- 499
-:= -- 1201
-add.period$ -- 72
-call.type$ -- 24
-change.case$ -- 142
+* -- 507
+:= -- 1233
+add.period$ -- 76
+call.type$ -- 26
+change.case$ -- 150
chr.to.int$ -- 0
-cite$ -- 24
-duplicate$ -- 290
-empty$ -- 636
+cite$ -- 26
+duplicate$ -- 304
+empty$ -- 682
format.name$ -- 126
-if$ -- 1647
+if$ -- 1725
int.to.chr$ -- 0
-int.to.str$ -- 24
+int.to.str$ -- 26
missing$ -- 14
-newline$ -- 117
+newline$ -- 125
num.names$ -- 34
-pop$ -- 193
+pop$ -- 213
preamble$ -- 1
-purify$ -- 117
+purify$ -- 123
quote$ -- 0
-skip$ -- 214
+skip$ -- 228
stack$ -- 0
-substring$ -- 358
-swap$ -- 64
+substring$ -- 368
+swap$ -- 66
text.length$ -- 6
text.prefix$ -- 0
top$ -- 0
-type$ -- 96
+type$ -- 104
warning$ -- 0
while$ -- 57
-width$ -- 26
-write$ -- 250
+width$ -- 28
+write$ -- 264
View
BIN  doc/report/main.dvi
Binary file not shown
View
79 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) 14 DEC 2012 23:25
+This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=latex 2012.8.26) 15 DEC 2012 00:34
entering extended mode
%&-line parsing enabled.
**main.tex
@@ -512,30 +512,29 @@ LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <10> not available
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <12> not available
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 1.
)
-(./intro.tex) (./implementation.tex
-File: figures/sstable.eps Graphic file (type eps)
- <figures/sstable.eps>
-File: figures/leveldb-compact.eps Graphic file (type eps)
+(./intro.tex) (./bg.tex [1
-<figures/leveldb-compact.eps>
-Underfull \hbox (badness 3068) in paragraph at lines 20--32
+
+]
+Underfull \hbox (badness 3068) in paragraph at lines 31--43
\OT1/ptm/m/n/10 Lev-elDB is log-structured and or-ga-nizes data into
[]
-[1
-
-
-]
-LaTeX Font Info: Try loading font information for OT1+pcr on input line 41.
- (/usr/share/texmf-texlive/tex/latex/psnfss/ot1pcr.fd
+LaTeX Font Info: Try loading font information for OT1+pcr on input line 52.
+(/usr/share/texmf-texlive/tex/latex/psnfss/ot1pcr.fd
File: ot1pcr.fd 2001/06/04 font definitions for OT1/pcr.
)
+File: figures/sstable.eps Graphic file (type eps)
+ <figures/sstable.eps>
+File: figures/leveldb-compact.eps Graphic file (type eps)
+
+<figures/leveldb-compact.eps>) (./implementation.tex [2]
File: figures/large-space.eps Graphic file (type eps)
-<figures/large-space.eps> [2]
+<figures/large-space.eps>
File: figures/mris-store.eps Graphic file (type eps)
<figures/mris-store.eps>
-Underfull \hbox (badness 7221) in paragraph at lines 138--147
+Underfull \hbox (badness 7221) in paragraph at lines 74--83
[]\OT1/ptm/m/n/10 When key/value pairs are firstly in-serted into
[]
@@ -546,13 +545,16 @@ File: figures/ssd_vs_sata_write.eps Graphic file (type eps)
<figures/ssd_vs_sata_write.eps>
File: figures/wiki-image.eps Graphic file (type eps)
- <figures/wiki-image.eps> [4]
+ <figures/wiki-image.eps>
+Underfull \vbox (badness 4713) has occurred while \output is active []
+
+ [4]
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <7> not available
-(Font) Font shape `OT1/ptm/b/n' tried instead on input line 177.
+(Font) Font shape `OT1/ptm/b/n' tried instead on input line 179.
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <10> not available
-(Font) Font shape `OT1/ptm/b/it' tried instead on input line 177.
+(Font) Font shape `OT1/ptm/b/it' tried instead on input line 179.
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <9> not available
-(Font) Font shape `OT1/ptm/b/it' tried instead on input line 177.
+(Font) Font shape `OT1/ptm/b/it' tried instead on input line 179.
File: figures/mris-write-ops.eps Graphic file (type eps)
<figures/mris-write-ops.eps>
@@ -560,40 +562,39 @@ File: figures/mris-write-thput.eps Graphic file (type eps)
<figures/mris-write-thput.eps>
File: figures/mris_ratio_ops.eps Graphic file (type eps)
-<figures/mris_ratio_ops.eps>
-Underfull \vbox (badness 1558) has occurred while \output is active []
-
- [5]
+<figures/mris_ratio_ops.eps> [5]
File: figures/ratio_ops_predict.eps Graphic file (type eps)
-
-<figures/ratio_ops_predict.eps>
+ <figures/ratio_ops_predict.eps>
File: figures/mris_ratio_thput.eps Graphic file (type eps)
- <figures/mris_ratio_thput.eps>
-File: figures/ratio_thput_predict.eps Graphic file (type eps)
-<figures/ratio_thput_predict.eps> [6]
+<figures/mris_ratio_thput.eps>
+File: figures/ratio_thput_predict.eps Graphic file (type eps)
+ <figures/ratio_thput_predict.eps> [6]
File: figures/mris_ratio_iostat_thput.eps Graphic file (type eps)
- <figures/mris_ratio_iostat_thput.eps>)
-(./related.tex) (./conclusion.tex [7]) (./main.bbl
-Underfull \hbox (badness 10000) in paragraph at lines 114--119
+
+<figures/mris_ratio_iostat_thput.eps>) (./related.tex [7]) (./conclusion.tex)
+(./main.bbl [8]
+Underfull \hbox (badness 10000) in paragraph at lines 118--123
\OT1/ptm/m/n/10 life-time. $\OT1/ptm/m/sl/8 https : / / groups . google . com
/ d / topic / leveldb /
[]
-Underfull \hbox (badness 10000) in paragraph at lines 138--140
+Underfull \hbox (badness 10000) in paragraph at lines 146--148
[]\OT1/ptm/m/n/10 Wikipedia. $\OT1/ptm/m/sl/8 http : / / wikimediafoundation .
org / wiki /
[]
-) [8] (./main.aux) )
+) [9
+
+] (./main.aux) )
Here is how much of TeX's memory you used:
- 11123 strings out of 495062
- 201716 string characters out of 1182644
- 249721 words of memory out of 3000000
- 14004 multiletter control sequences out of 15000+50000
- 20631 words of font info for 64 fonts, out of 3000000 for 9000
+ 11131 strings out of 495062
+ 201791 string characters out of 1182644
+ 249735 words of memory out of 3000000
+ 14009 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,345s stack positions out of 5000i,500n,10000p,200000b,50000s
-Output written on main.dvi (8 pages, 59220 bytes).
+Output written on main.dvi (9 pages, 61788 bytes).
View
2  doc/report/main.tex
@@ -179,7 +179,7 @@
\input{abstract}
\input{intro}
-%\input{bg}
+\input{bg}
\input{implementation}
\input{eval}
\input{related}
Please sign in to comment.
Something went wrong with that request. Please try again.