From 354e507c678911e21a8561e87d71c46fcbfd4058 Mon Sep 17 00:00:00 2001 From: Ming Date: Sat, 15 Dec 2012 00:35:28 -0500 Subject: [PATCH] finish background flash ssd part of report --- doc/references.bib | 12 ++ doc/report/bg.tex | 208 ++++++++++++++++++++++++---------- doc/report/conclusion.tex | 10 +- doc/report/eval.tex | 32 +++--- doc/report/implementation.tex | 80 ++----------- doc/report/intro.tex | 6 +- doc/report/main.aux | 119 ++++++++++--------- doc/report/main.blg | 50 ++++---- doc/report/main.dvi | Bin 59220 -> 61788 bytes doc/report/main.log | 79 ++++++------- doc/report/main.tex | 2 +- 11 files changed, 326 insertions(+), 272 deletions(-) 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 a9d06e164ddf5831d76d75531cc7e7e58de55871..d518cef7243251a4104ddc371e30cad038bcee55 100644 GIT binary patch delta 9188 zcmZu%33wDm+Mbz?m_Rr}LO>8XL?lQiHzBY>CM1vmNgxR~Q93i7$-vC?*gcaF9&rR* z6g6X-l5u2!1O?WB7Y-s>F9cn6p9Q%Q2$z6AUW+Tb9;@)bRn-$&pXGT-rMj!W{^~p4 z@2#pFJs@;^CNvN0mNPazJuCYOgTY`V?`?SQP z_W8)a2ft{HY3qK}7kPf@JX1_d_oMZZ>%-Dwj9ZC0rE-KvkyOd;RfEEW_q=rysS&M< z?TYMk+lX9CCOJj5j#O3_jv@mexWhk66DD03-L|kWC}VN+=XR<2WNTwuee)iJ==4cJ zVNj;(l@-aX#r&9BDOtS^*-f&DO;W9jqecqJJ_ViBz$T`d>ae?m!qgbZBMz6xDY>AB zNavWfTb6E_t=-7Vm58)X^4B-%&=mLV&PFO9omJTP^Huduc^Ur6vruJ7Dmk%_13+ znV1|FhHA`i)KV~tWD8++F!(@6P#CgI|DsbCZE9E;@}N(3xa~wFE}zruNcB1-B_t}= zI)@hq_bC$9S9Pe~sF^XCuH|NDvSqnMe97yulH$TbbAUXw{ccir&r1KYso7Y_^^Prv zGR+wQ?Y53BECw{eU_clI+Irc`*z0!oI4G?7mjha@`A#I>Mh|RM8*T zhf^Xh$t5d|+KsubX01zwv#L%~Bxo!VFI!n)bG*U8M7l(W8!j$Np^{XH3JXOeyVC&t zT?8VqUTvszSnCKxgxsPFJ``)cl0py|)P+#JY~5D7rL0gh4cH6^22BIrDJ!o)Z;Mm5 zJFNKSZF}>zT)1B)^T$-1HPcV2Wg$Mnzr~@_0W`{>HbPDIFiS$L&nYTF)79a!TOvLc z-*vddrmJ_uERd6#0YNeLu4T>ox39)g)kAQMhd5Ls*1!~AS=Z33h@PNn==YKnPE+8p zuxaSE8p+$>mn1iFcvTYB5Ze9nG;9U|$WtqlsFrlj(xq8t1zGHo-8MC7x^I|QMs%>H zicXSl)`TAA;83Men#uO1!;2v4oC2+gs7rGCsf9#m(Dde&49wg=qjNoPp0tWs z@0(xLNTk-MP=PRk&4J{vci0fK4mSik><+O{C#h(@6b8+&)(gT!l5% z&_zNbfjC9dQAo1+Y2u2+Dmk6Vs`zSulNQ^tHL8TraX$;Yu+Xu)PDBcIw2Nw^%O!ag z1hOKDhy}MT)Sw_4bdW$GM*YX|!mP!~wG|i{j9I@9eyLsexm{GfEG4|+Vt)uh0r<1m zIU7k%`n9gzT5HA|x&mkE|1MUS%aM`(y35y&naI(o-PkI(E#^@mgig<98bEwTdTM5R z*t89)>Vjm|DZ^e3ELuf(h-wTghfWo<$50gOMWjj8sK8c9X@0h4lopfp1zS>3*!NGG zZTqfTWdJ4|MG*`Jqozf4s8YyVCwe<=>z2K`7iuKUbVO7s%r=HiM;6L!Pqx+*gaq{T zN&wuL#J?6uSdm}i)>9EESMtPAjZ?NR4q`6M9fE&-?x;0wQ0~yTb~z|KeFlLcJbhMD zL=|RNWUFMOK*Z8C1S4doW)WGz1RA^)cN|e6Uf^m_xK;$atYdcZV=bav6Rs6<+uW+! zOQXulQi$rzO)|YtXHa~1S%;`=MKo@rNg=v}rYAm?+)NkQ4SzZvE*ko@Xjz>MVKmbd zC#c#0N%-O3!Bu`5*02Ljl)wQdH!2T_tOkwWjHl2g1999O1ZWsg^cL-sX8dM??hQP3 z(J*JFlNmx6BRW+%XiD+}rM9 z&BWr2nh%xB;jMEa>&pi^Se2rs0jZy=dKDil2dHougU49VoJ$RosL+gXc1D2+Ht6PS@R8rzM*voH+vhk@|Fz=q>F;HPhaZuuabt|+xj%g%wIs(D>qI4s5tTwlIf5wf)GH=9x!+>ZEk}L0)lw$V_D4%0YsVLqvNljKiM1yR zidZ{nVgYMy6Yn(Uk;f)xvEDlqOIX{ru$;9E3j4>kbl+`ab%i`w$mhIQIGw#sDw@Vx zYtdxZzEs4&eZ6RWG>$%)Tn2;oEk11$y6+YuKTP@F*fS=t65N2op%jeC`+zK8k?4=f zd*35EKo}iPCoOWSh{UT8A#v~qC^1c+PzeJ@iAzJBWkY&~D1h=(W^>f067l%R*y{xX594np1rQ+*PPX`$z08BL z78vb@PHQ)MoG_jWUOCUB^Lspj+_f8MtwKFy98Q%zbzsE2UWP=cT~5_mC(?u=Xi(_& z1!mYJz>~`Xeh2jccX-6Uz!-_LkODSgPGub1#$XsCBn2Q!(GCTduu4N6M!4y)cTr_h zCwtwJ3hTlsq7^!;5QNgJxGBvU|7nw!7`vIwF3)F4ysn%l_Z7W=&-6*`xpz7Tg^#As zV*MdAc;7c;T;i#zQezdR;O!2T`i>&Nz8TZlxZV}TtgWudygT{ZEjj>XGXN;6Z@y5% z_E*?>f#2VGhR@wqQRat?1{9cJ%q{n2OfCq=#QegUI9~>qDy4!*N~8n@%sHYWB{WBp z-6N_>Q*;F;PM@g>c>^=eW6~!VRXEH0fy*|7yQzeDd9x}$9 zo=yDp#Ih@VAsy;-LykAuOy z;EpcJA8AguQ-%KP4dc@7EbmT`ujj5J{_Vrbg!}VN#V?^qxk_)C)6fO1ch521u5);1F>(-Ka6K<+oZ_nek#WbJSsj2gMC3h*S~rydtRrvyQ(Lma>f44E7y%`UiBv5$E9fZ@&3vC@}re1 zA{L_v-w;RP&?ok%NLtMvaDcoN;;u|3XBOJA#zL_+uHV@EIjWK$tR*)QmO>lHoF*G5 zCWmdAacw;}q;sU|Dseh9U7Es>WrM_#>%25!Bpj(q5BLDl4$-N>1tn?aD$G6L+R~^8 z%^-Kf08k~h!(#h3C3D2_)pFF^SIfT`YtQYIO=;c0Cnzw$w|c~pDtl^D7WUi1E%hZJ z^eBaj)E(7{ocHu4FWLup0WqX_8d#KzTK(~&R>8mTWh8CbwC|-_9Qc5;FtQR-UBC*k zT2NgzG=lY_d$WwpF;feoK!)%QnpPiVB36Hbt+?#;VTi4?8GQ)2JDLo{Uf8 zFiRzieAuJ{=SJV98v!R?ra5z&MswzQk>O6*BYvU9>8+#NR|1qmsdKWup(6R2QYtiN zKnngKQEozQ(WndbVk`I5KD>x-XFxX^VT~HeDgp>K;iu; zV7b^u@MAZFVK%%af!6N7&fb&Fo=G=l?6)4Cc{vYorupClQ&-Vn;wUX``D3HAKcgbBF&>`v^)MG~v*0Yzjz&8|QODbij17 za%t5KWu=f>MRu`M`Obn(6As3*iCz(`I^#Br2YZ7hE(bp2WM{bGSs(u$-wO(l9+N$4 znkret!lTE548@H#io*s@LeKPuhp5I&q6Zc9d=KP@)?-lU5m_nbz}6O6gna+ZDj``8 zMwW$ML9CMWb)V7_)qP0ZP9CK3p{Acx#P1=&8ugHK6r2=giZ!q_ZzSkOh?`~(sBe2F0`1fyQ z$A&qH=jZoqACb*GeA}~7kJh8xH*!7dHde9kzq_%2x2-Kbb8R#-R`(_Uw{abxm&4{I zpZX`CH)spZ=Y?CAn~)K9<2;@WZ}womA}_TrgK0)?S`?ps@oOIIzbC_QCcJxXvlV7r z``kft&x`As*-pM#5rc!(cJk$4X555;mKQkIJo*Ahwtu|95%0D(&Mw5ZF{Iw#pX_Yw zN8a(X+=Udfu`QXTZsS9jZW};Tnm!J1<4AUS8%M6(?Zr`qN_(k@BGgNVjop%mt;6yu zTIWP&A_{Qmk{ZJxVZp1n#r7WdFC8CV9X@Z3ibQGj?#2vT+AD|Cc*P8#Bp}*Akf%a$n=4mc2G1KBF47Rxdi_qu2QEsc(cc zp@orgJw{j4ZDr?>wg|_y>k)pcQ@#_Y3-LwZXw=>EP9A={b~5N(^Ew|i<8=;xn_e$x z3S4`gE0DK~^Pfj|rLpJjyGHiUOs~f7oL|vlM@^(2(fUb#+r`C|y}?%(euMYF*86$8 zEueo}cc){mCw32kxqsdLe@0_=Ob)hV~QtV84$t?y=Z{089 zVBKjZ^D}bEpY~)kKvef|pxnEsVgf_}l>iF-W{_Tf;qU;r9EzI~#_prKu|S%H(`p%e zKhhX9eRH-`W;&^O&&*`5d~X74KX{Lq%!IwXBuabvw|4I31^qvJIXIW>8+cd0Usmd2 zH#(s8>ew=oUGq_VRe{N=Z}QxFVjmCPGy8Z#41J$Va=gzI<(2n&5x((0kN#;N@bMcz zD4{1X^wN&557!@A=G-jMJ#(Nf@l1TYO8$DT9afSX9OhMR_Vz5@*l zfn)SQgC4TzcP=1jK3gN@Z@8bbNlxtLbj<$!J}@Z!^P9!Z?mynoQq$7&T6$W+&S*fb zr@UaT6BY1bJf$Zj^x7?2103D-bC#t~+LX?NA23>>Jxx?e1J2sRAPo4GowDqCBgs!{ zB{7Qm^fD4xG+!mv;D`|?OJU)wK2&Xm-tpoy?Dm5&*koth(Zekw*DL~;M*#3zREiUZ zplOxp#Q_$sKsyiA=;mBAty+kJ5-ne(_eaT$AH(z>EDPrVPKWB!%MRa#W1oxSLuP)o zWkA1QR&d~{kZ`0#Pm~dQ@P2~vRr0`*J0e*hw;5wvde2ElZ&2jM-+wg$?Z9IL$ex4!gq~MsGdVvT>_a>!V@Qufh3x&zLwsJ#q4BJL z{t%xx=x{D6KAB9MhxvCOIb6c}7Z3OGLrG>0E%u>!u=dXT+2p^i|B`OP$7+UfYg$^^ zaCsqaht>|>)8JU_@JKd?XvR%W^XcLCG@L;!cBF-v7+N%qw#wB8Lv5|WR9gpHL!F1O z@a=+Tc=lOD{#H5;T<iL6iQx_6m_Z#_FMhE_tP+ zUrbvsg8@<1pZt2Jw?H5M*l{mwbI;6R?GtB;dg3`Q6AL9PE)+8|t4aCcfy8-^k54#T z&c<2K7O{5w*~zT^;p{lpW}Ul}%sQM*-ag;E3UVxN(JQ+ErtHrGkPtXQ6`o!9N6$Aj zG-x-LeooyFChA*~su>`#O<-;O zd9K8i^X0eV^{^$;FXglTKQ3jE&3Si{<=cm$REi%a4gASqxID|aa?PIG$HDIg z;fm>ndtWdfzqHwqfG806_a%!iKY+WVh2k1-eaObg|Eg}< zFKfO%s;LX_5jQ?o8#{WXN~KZ*zbd@BFtlg4IEdAbj~(r@^xP2OJGAv+jm^h2j3(l!0id$T_FSCRjW6;4h)*jp%@ZA z%1gZw3L^@u^@6OE3?+h{8{cTQO7-0MZP;ZfGXZbXI}ApPC>RBk!Yc-|DaxkdUYcR+ z)W!=AVRfsj0(jBND}oK@D&<1$M!GMHAeEXWBX827(sN>oJDK{DJ>WhV&g($i$~bJF22Q^z-$pr z?rHF9Y&N`@`3wX+yUg!DAG}&)d)U6Up>t9F4*2Z#V2GJep*{!OCS>>oMogsNTHw3b z$zEH0RVvrh+Tj}RtpSiV<_&e6>+3PqTxd-68|Qk{10sji)uNN6c%|J{HqNQ;ioQeL z@biRx&(FNXNgC4iR$?BNR}+h=OrMxS?i7?hR(THQmKs-vWShYtYn{{^Rwx<7Wg2g zfZDh!wZN;%&-9*aYU)@uJiHeQ%O@SsHrCjJytky-H1d7D#Mhl^s4U@i^X(cX8bd*6 zHd=Uk{$P-88YM<4=M`|d(ke9SMi`!%Nvy} z6*%ob>S`{z`~13VWx~2M4OOEm>RMF@97IQQUxQ5IS2pMcNzj90h7v?m@>3!&)t$Ik zCJ+!pr9l+2A7sAn@bLfDvbbY_^meWREu#gO1XV#{MQRBKsJWa$~*5 zUW13E7ZgD<8cc!%{f!f`tD5R}phpEs;SH2QaO)P{AR&S6@f@oHK!TcFo z3g?Y87|id^NT%)BnHf|roXP0n*v#i>J7N}VzdS1;s6AV#Dyp&w&|>f`2W_)*=(s+! zGpW?ij(sMqdoxlfnsq{3Yx8g4nqE=YkwtR=5_+xEKk)_w#=hBk$vCPKU1sOR%`uZx z>p5|QQ9v(Ok&w1=;wBy)AdJ)zzt5aG(=n-FdK46uWAuxg@(V{`Xm;EgMmPxq=Z}Q^ z5+fpQUrBzoGjQ1oMnlu7+f0hp&aJ#D3sMDAjerSk<&CjX(Q$|xrJT7&G6^Drfqa#5 zpP-G3jT$$?#?@X%NEl4A!iyq;im*1-Y(`w^<9W#C7ho_!d`|4>=)!26HhQF?+N3MD zar&`^DYl1KP8HcY1Ma0@J32EhEehOmh4F+?ev}VoM30@j@8>yXJbMh9dhWjO<4Ww@ zy?dyHc!vx|-#9WvUM`0co~SDDm-O6eS%r4>FN0~oN7=aBU5NM8 zzoZc@1`HsKCI|0eMv#8D9S-6cs>^#bZ|9bV>v&`igHlz`EggysjmAz+rM$yCBr{9= zya=*Iz-^d^l{(^MqoYBx7^B=ua9O*T-)`KY&C72Zx)f0b-HRC_k+-$c(UWc5^LEcV zw$51%SV{D(Bon#k|EV)$?k3@0BA|1PJf?XhAFGHA#$#|;tR;`i0fSDgvU7`7ln4on z8brcafGMP0Q7rQKQKQPxI%`SYT4xk&E$-7JloSpdE7ND(ZIlY;K=E?J{B&ov7dlVSmHo8(aZ+mGr?f=;=)5<1!@>E?J zOK_*ln2N#WtUa$h8S~OGaPrAqMkOXE6C~(N2$UvWL6-*Ahh8@!KsOwc=9fWYvoE;j z&-MvSpYP68JIXU@rh;F~M|d^)Zu-a-X=r^^hlGk*#4rRgl#7f&nnhM`{4BNE8-geQ*VfDcsw? zb2VFTy@~PHEfZUAlsTRiXHTyrAjd;-6Cx}$k5tD%lX)Or`>^>LQpWh!)HMA0(dGz> zWY>m@|ESR)s}_JyU>25dSeUfHujY7`qhl-$n(C#$BOIX=voqEu2wPr3Ap9m9krcpS zQQ82R~FNmCmP5>z_) zDjN>N^o675x-}9)L9^`|d7H>r2@>K`$CDgsF2$N|yPL&zybcvd$W~oB@G|5IMh{Bq z7bG!l+ng9}aU||d6;p(H6=0fm@L=i;nq-g~WCcqbyXL43_eIJhxn6U$4jk4&fevIj zFd_*UJZhoMI(WDt@ZG<-0 zQ!eGTutzw5Vfhpf&UY@KOo8;r@?0u&Rt$~^*)Kc-Ya9iu$KBJAH__WOIfh#MifMGx z4=ZL-Ie8^hvSww9=W^lQ_rJ&3(Hvj305_clYkbE~-Aucj$KN-TyX?-l{^an}L%ZM; zstTl^THwOUBxXr!-qhJvIJbU<&!suNS|Va1YisEpFnv`rx1c|{ z0{H#8#a=?~b{^gJHQBdo*_u=2Am*%{j{i2V)#ATb*FM*)LAC3-xpZVh=d_f?^hPyz z(@RLl0dRX$k+(BoO-EC&cM6R7Gyp9&%vC42DPr-qU%>K++_l%Q7GW%X+9Z*)^8_29pB| z7;QXFq1wo5N2z2sl3TRnuS~4x6`m$~RFz`E%6@^-fK{8e@Xy3|PN2u@-x3oWC#srN(CJ^CRRo=4y!C&=}R*^W7$1+tWgmKECCZXgmYyJG)XlUpxnJ&=4&~2{5uxa01gkkf+{UbE`8#-s!4WnOk-ql0%yYqbG zzrj3)asL-&=BQov_cxL78@EH(-5IpxfjiNCzTHg(>ZT=}Pm^ErZ;X+)G*9(VAJ(9CL+&#nl^Izk8|RO;@6i(=Yi~rtp|+Za8iU zODMd&stQw9FUcu_l)FAUvuKtETFjPO_l>)77vsPUyBO!)-IWPT-zifMA+)B^%xQv+ zJJzEiiOo7MJn9xm{4kwif7yp$t9yie)`C984=3VWb3azApJ646D3F^ZDe!5bK@t#_ z30SQKgfC(AL%?c`xJ1_)qeNpdI)mM(SBB zsWlIKrR#2_hmYUr-9Njo zR%=~9{c8y4)fCujb%h?_u>%%-F<3nY>c4ni9S^^K(HCD|LJq#-39+<8j~;baA4(Xe zEw*WbyOL_VkYC_Q?t%%gBA>hx!kiqDirDD}nqC=7j+ch6U4@aFCO~R7g zgk%MIeeNP%IWJ*FEJy}SE;^Z%vh+CxA8_cYRTGby6uVb+kY1usIRt>DzFi-N1!1Lt zwI?szyrP5Y+e#(Yclb0*EF^bHoxxWJr2>ye37%@O1mB&>n~?@9Qc|>%ghnhOS2Unp zY}1rkNaT>`v0(Z>W-ghBFG=KC=h)R;EE($#8q|A8j)w7vy7wo~SiBxzp=J#CJfhLd zxdGqEW<)~Yd{?1+T4WgVX=n-8D6^gzpUlzw>e>oM=*aZSsGx_)%XMSGRBePDahaQ|QcY&g`ON=N#gXRGF&XS=bVpGo`g zpHHGI&1(;&?Ku~csr=`K1S;Dv6!@bbb9sq8+bmY$)5SQrbmtkk`rRPNxDW!Si>Z{_ zp!uTc)zmBV4;XZ*AI!NJ1O=CtLgJ+$xO!*-YXx-pr`SvL}>TytXx{M->192@=rd`lK7znMV?HQ!94 z^1)3uDdtvwSNu-iZtipp2#$?;!rYcyY|ihuX3)9Qe;5sWE`>qS%>df|@P{la)wlbT z4Zzl0tbfXF)^ER^Nxyg8P7cJiBJ!u@rMXYAZQ3a^H fq4@3_kx%+#%Y!HVoy^tq-ek4U)iK;f`rrQnDzxGy 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}