diff --git a/doc/references.bib b/doc/references.bib index 16418e9..968a1af 100644 --- a/doc/references.bib +++ b/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/}", diff --git a/doc/report/bg.tex b/doc/report/bg.tex index cf6db45..00967ee 100644 --- a/doc/report/bg.tex +++ b/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: diff --git a/doc/report/conclusion.tex b/doc/report/conclusion.tex index 184d6a4..7c39d15 100644 --- a/doc/report/conclusion.tex +++ b/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 diff --git a/doc/report/eval.tex b/doc/report/eval.tex index 34c8c48..7833f4b 100644 --- a/doc/report/eval.tex +++ b/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}). diff --git a/doc/report/implementation.tex b/doc/report/implementation.tex index 4169074..59de85e 100644 --- a/doc/report/implementation.tex +++ b/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 diff --git a/doc/report/intro.tex b/doc/report/intro.tex index e89e980..b5d1b3b 100644 --- a/doc/report/intro.tex +++ b/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}. diff --git a/doc/report/main.aux b/doc/report/main.aux index f20b934..e8e3ca4 100644 --- a/doc/report/main.aux +++ b/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} diff --git a/doc/report/main.blg b/doc/report/main.blg index d15f806..add25f7 100644 --- a/doc/report/main.blg +++ b/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 diff --git a/doc/report/main.dvi b/doc/report/main.dvi index a9d06e1..d518cef 100644 Binary files a/doc/report/main.dvi and b/doc/report/main.dvi differ diff --git a/doc/report/main.log b/doc/report/main.log index a48fc43..ad17112 100644 --- a/doc/report/main.log +++ b/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) - -File: figures/leveldb-compact.eps Graphic file (type eps) +(./intro.tex) (./bg.tex [1 - -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) + +File: figures/leveldb-compact.eps Graphic file (type eps) + +) (./implementation.tex [2] File: figures/large-space.eps Graphic file (type eps) - [2] + File: figures/mris-store.eps Graphic file (type 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) File: figures/wiki-image.eps Graphic file (type eps) - [4] + +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) @@ -560,40 +562,39 @@ File: figures/mris-write-thput.eps Graphic file (type eps) File: figures/mris_ratio_ops.eps Graphic file (type eps) - -Underfull \vbox (badness 1558) has occurred while \output is active [] - - [5] + [5] File: figures/ratio_ops_predict.eps Graphic file (type eps) - - + File: figures/mris_ratio_thput.eps Graphic file (type eps) - -File: figures/ratio_thput_predict.eps Graphic file (type eps) - [6] + +File: figures/ratio_thput_predict.eps Graphic file (type eps) + [6] File: figures/mris_ratio_iostat_thput.eps Graphic file (type eps) - ) -(./related.tex) (./conclusion.tex [7]) (./main.bbl -Underfull \hbox (badness 10000) in paragraph at lines 114--119 + +) (./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). diff --git a/doc/report/main.tex b/doc/report/main.tex index 52d9801..c6ccaff 100644 --- a/doc/report/main.tex +++ b/doc/report/main.tex @@ -179,7 +179,7 @@ \input{abstract} \input{intro} -%\input{bg} +\input{bg} \input{implementation} \input{eval} \input{related}