原文

文章看了三天都没有看出所以然来。

今天重新看了yangsuli 博客，发现原来文章所谈的就是我读的那么回事。至于为什么我没有看出东西来，是因为我不知道这篇文章是要干嘛的，难道只是对trace进行了压缩么？

Main idea: take standard trace, then divide them into chunks, define feature function to turn traces into a muliti-demention diagrame, to trade accuracy for size reduction.

将标准的trace 按照时间点（文章谈到了在trace可能出现的误差点或不精确点chunk 作为分隔点）或者块大小分隔大小，然后根据特征（读、写、偏移）函数将traces 转化为多维度的图，然后通过重复数据删除和benchmark plugin对数据进行压缩，以减少精确度换取size 的缩小。

我的点点想法：

1. 重复数据删除在算法优劣的评价下并没有一个数据集合，一方面是如果真的有这个数据集合也会是非常非常大的，它的存在价值不大；另一方面更需要一个精简的方法来衡量算法的优劣，这个方法甚至可以自己创造一个数据集合对重复数据删除算法进行评估。重复数据算法实际上就是压缩算法，比较压缩算法的优劣也没有固定的数据集合，但可以通过压缩率来衡量，有人要说压缩率对不同的数据集的压缩率也是不一样的，好在就在于压缩算法更容易用数学来进行考察。这样有一个方式就是通过比较重复数据删除和固定压缩算法的压缩比，但问题又来了还是需要数据集。而且数据集合取得不好的话，可能这两者之比相差非常大，比如讲一个word 文档复制后重命名，重复数据删除这两个文档几乎没有压缩，而压缩算法对这种情况却十分有利。
2. chrome 客户端写一个插件可以保存指点图片/链接（右键该图片/链接）、保存指定文字（选中该文字）、保存页面（页面上右键）到远程服务器（可以考虑ustor 哦）。在本地桌面安装一个快捷方式可以随时查看以上保存的文件。有人要质疑这样做的好处了，本地不都是可以做这些的么？但没有感觉本地在保存图片和页面的步骤繁琐，还需选文件夹，chrome 还要卡卡的以下，能够让远程服务器（云端）做这样的事情，我们只是单击下邮件或者按下快捷键是多么惬意的事情啊？有一个小小的问题就是如何认证所在的用户并保存它的数据到他的远程文件夹（显然是要先注册的）。

文章结构

1.Introduction 引言

2.Motivation and Background 动机和背景

2.1 need for insight at different layer在不同的层次上了解

2.2 need for multi-dimensional insight 在多方面进行了解

3.Methodolgy 方法

3.1 trace analyzed trace 分析{1000 employees in marketing 500 employees in engining}

3.2 Access unit 进行存储访问的单元{sessions，applications，instances，会话，应用，实例}

3.3 Analyze process 分析过程

            step 1：trace collection trace 收集

            step 2：select layers/define features 选取层次/定义特征

            step 3：compute numerial feature value 计算特征的数值

            step 4：identify access patterns by k-means 通过k-means 的结果得出访问样式

            step 5：Interpret results 解析结果

            step 6：Design implications 给出适应于反馈结果的设计

        3.3.1 Selecting features for each unit<step2> 为每个层次单元选择特征

        3.3.2 Indentifying access patterns via k-means<step4>通过k-means 得出访问的样式

        3.3.3 Interpreting and generalizing the result<step5>解析并概括结果

    4.Analysis result&implicance 分析结果和含义

4.1 Client side access patterns 客户端访问样式
            4.1.1 Sessions 会话<观察结果1-3>
            4.1.2 Applications 应用<观察结果4-6>
        4.2 Server side access patterns 服务器端访问样式
            4.2.1 Files 文件<观察结果7-10>
            4.2.2 Deepest subtrees 最深子树<观察结果11、12>
        4.3 Access pattern evoluation over time 时间变化下访问样式的变化

    5. Architecture Implications 结果在系统结构上的提示

    6. Conclusion and feature work 结论和未来的工作

内容：

文章首先提到了先前文章的trace 分析存在的一些问题：

• 带有经验主义的偏见
• 单方面、单维度的分析
• 分析的层面较为单一（文中从至少从Client session 和Server 等层面分析）

文章的实验样例有两块，一块客户端是拥有1000个雇员的商业市场公司，一块客户是拥有500个雇员的工程人员的公司。下面讲讲文章核心的12 个观察：

1. <sessions>The sessions with IO sizes greater than 128KB are either read-only or write-only, except for the full-day work sessions. 除了全天的会话，超过128KB 会话的IO都是只读或者只写的。
2. <sessions>The full-day work, content-viewing, and content-generating sessions all do ≈10MB of IO. 全天工作、内容查看和内容生成会话IO 约为10MB。
3. <sessions>The number of human-generated sessions and supporting sessions peaks on Monday and decreases steadily to 80% of the peak on Friday. 人为产生的会话在星期一为顶峰，之后下滑，直至星期五下滑到峰值的80。
4. <applications>The small content viewing application and content update application instances have <4KB total reads per file open and access a few unique files many times. 较小的内容查看程序和内容更新程序实例在每次打开文件的时候都会有<4KB的读并多次访问一些特殊文件。（理解的不知道是否正确）
5. <applications>We see >50% sequential read and write ratio for the content update applications instances (corporate)and the content viewing applications instances for human generated content (both corporate and engineering). 内容更新程序和查看人为内容的查看程序有超过50%的读或者写。
6. <applications>Engineering applications with >50% sequential reads and >50% sequential writes are doing code compile tasks. 工程应用有超过50%的顺序读和顺序写是在编译代码。
7. <files>For files with >70% sequential reads or sequential writes, the repeated read and overwrite ratios are close to zero. 那么>70% 顺序读或者顺序写的文件，再次被读写的概率几乎为0。
8. <files>In the engineering trace, only the edit code and compile output files have a high % of repeated reads. 在工程客户得出的trace 中，只有编写代码和编译输出文件才会有高比率的重读操作。
9. <files>Almost all files are active (have opens, IO, and metadata access) for only 1-2 hours over the entire trace period, as indicated by the typical opens/read/write activity of all access patterns. 几乎所有的文件在整个会话（trace 追踪的是会话）周期只有1-2个小时是活跃的。
10. <files>All files have either all random access or >70% sequential access. 所有文件要么都是随机访问，要么就是超过了70% 的顺序访问。
11. <deepest subtree（我的理解是只包含叶子节点的目录）>Directories with sequentially accessed files almost always contain randomly accessed files also. 目录中有顺序访问的文件就也会包含随机访问的文件。反过来，一个subtree 却可以只有随机访问的文件。
12. <deepest subtree>The client cacheable subtrees and temporary subtrees aggregate files with repeated reads or overwrites. 客户端缓存的文件会被反复的读和重写。反复读写往往来自一个客户端。

文中针对这12 个观察结果给出了相应的提示，具体参见原文。