以下内容来自于两个博客的内容合并。
首先是来自于冰山上的博客的关于atime、mtime与ctime的介绍（我估计作者也是COPY来的，因为最后两段明显单词断行了，没有修改）：
原文：http://xinsync.xju.edu.cn/index.php/archives/4683
atime 访问时间(access time)：访问时间是文件最后一次被读取的时间。因此阅读一个文件会更新它的访问时间，而它的改变时间并没有变化(有关文件状态的信息没有被改变)，它的修改时间也同样没有变化(文件内容本身没有被改变)；
mtime 修改时间(modification time)：文件内容最后被修改的时间。如 echo “Hello” >myfile ，则myfile的mtime被改变，同时ctime和atime也被改变；
ctime 改变时间(change time)：文件状态（status）最后被改变的时间。如 chmod a+w myfile ，则myfile的ctime被改变，atime和mtime都不变；
参考：
st_atime
Time when file data was last accessed. Changed by the following functions: creat(), mknod(), pipe(), utime(2), and read(2).
st_mtime
Time when data was last modified. Changed by the fol-lowing functions: creat(), mknod(), pipe(), utime(),and write(2).
st_ctime
Time when file status was last changed. Changed by the following functions: chmod(), chown(), creat(),link(2), mknod(), pipe(), unlink(2), utime(), and write().
然后下面的内容又来自于知道分子的博客：http://hutuworm.blogspot.com/2009/03/blog-post_31.html
Linus 大神最近将一项名为 relatime 的特性设定为内核默认行为。（参阅：Matthew Garrett，Reducing disk use）
UNIX 文件系统中的 ctime、mtime、atime 属性分别记录了文件的创建时戳、修改时戳和访问时戳。每当有进程创建、修改、访问某个文件时，文件系统就会保存相应的时戳。对于一般用户而言，文件系统自 动记录这些时戳所花费的时间根本不值一提，完全可以忽略不计。但对于某些特定用途的生产服务器，比如存储大量小图片文件的服务器（写少读多），若每次读取 一个文件都要修改该文件的 atime——想像中的单纯读取操作，实际上却是一读一写——如果这些服务器访问量还挺大，那么这个过程中的消耗则无疑值得斤斤计较、细细考究了。
以 往我们为了节省不必要的 atime 改写，常常采用的方法，是通过 mount 选项 noatime 挂载文件系统，完全摈弃该属性。但随之而来的问题是，某些依赖于 atime 属性的系统程序无法正常工作。而 relatime 补丁的改进之处在于，仅当 atime 比 ctime 或 mtime 更早，或者早于当前时间 24 小时以上，系统才会去修改 atime，由此就大幅度减少了 atime 改写操作，提升了文件系统性能。该项功能已在 Fedora 和 Ubuntu 去年的新版本中发布。
其 实，可以节省的地方还有很多。上周小算了一笔账，某个页面引用的 js 和 css 文件 Expire 时间为 900 秒，一部分图片的 Expire 时间为 12 小时，另一部分图片的 Expire 时间为 4 天——假设该页面内容不变、访问量不变，那么一年的相关静态文件总下载量为数万 GB；如果把这些静态文件的 Expire 时间统一调整为一个月，那么总下载量可以下降一个数量级，降到几千 GB；如果胆子大一点、步子快一点，统一调整为一年，那么总下载量还可以再降一个数量级，降到几百 GB。阿米豆腐，这样的估算结果真是令人咋舌。
这两天又看了三篇跟性能优化相关的报道。一篇报道是 Linux Magazine 采访 Theodore Ts'o，其中提到 Google 的工程师向 Ext4 文件系统开发者提交了一个取消日志补丁，以获得更高的性能，可以看出，这个功能对于 Google 非常重要。一篇报道是 Red Hat 官方新闻，说 RHEL 5.3 开始支持 Intel 的 QuickPath 内存技术，运行内存密集型的应用可以获得两倍性能提升——显然这得归功于 Nehalem CPU 的崭新架构和超强性能。另一篇报道是 Linux Kernel 2.6.24 到 2.6.29 横向测试，OpenSSL 在 2.6.29 内核上测得性能比前几个版本高出一倍：
无论如何，关注这些信息，稍微算一算，我们就知道随便从其中找一项出来优化，可以提升多少性能、节省多少资源。虽说咱不差钱，但能省干嘛不省呢？