文章结构

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 个观察结果给出了相应的提示，具体参见原文。