kai_ding的专栏

前言       前一篇博客中我们仔细描述了Linux文件系统的主动一致性，即文件系统对外提供的用于实现文件一致性的接口，应用程序可以调用这些接口同步文件/系统的脏数据和元数据。但诚如前一篇博客中所说，一个成熟的系统不仅应该只有这些由用户控制的同步方式，系统需要提供一些方式来保证文件数据/元数据的一致性。本篇博客我们就详细描述Linux内核中这种被动一致性的实现框架以及部分细节。思考

众所周知，Linux内核采用了page cache来缓存文件数据以及元数据。既然采用缓存，就有可能会产生缓存数据与磁盘中的数据不一致的问题，本系列博客中我们重点关注Linux内核如何解决这种不一致。     一般来说，一个成熟的系统需要提供多种机制来保证数据一致性，其一是用户可控的，即用户能通过特定的接口去控制文件数据的一致性，这是对于文件数据一致性要求比较高的应用需要的语义。另一方面

前一篇文章仔细描述了最简单的一种预读情况：单进程文件顺序读，且读大小不超过32页面，这里我们来看另外一种情境：单进程文件顺序读，读大小为256KB，看看预读逻辑如何处理这种情况，照例首先给出事例代码：{ ... f = open("file", ....); ret = read(f, buf, 40 * 4096); ret

本博客主要阐述最新内核(linux-3.12)的文件系统预读及时的设计和实现，可能有理解不全面的地方，望各位能多多指教。所谓的预读，值的是文件系统为应用程序一次读出比预期更多的文件内容，当然，这个细节对应用程序透明，应用程序可能的感觉唯一就是下次读的速度会更快，当然这是好事。同步预读        让我们设想这样一种情境：进程P打开文件f，读offset从0开始size

1. 概述        今天本来打算写一篇关于linux内核sys_mount()代码分析的文章，习惯性地打开google，看看是否有别人写的比较好，可以参考参考，打开第一篇发现居然是自己以前写的博客，真是囧，而且也记录在优快云上，本想直接行使拿来主义，但看了下内容，发觉略有不妥，于是在那篇博客的基础上进行些修改和润色。        Linux下任何块设备在使用之前，首先要对其进行格式化成特

前面两篇关于文件系统的预读我们通过实例阐述了应用程序的顺序读而触发操作系统对文件大小预取情况，本篇博客我们主要描述预读如何解决交织读的问题。所谓的交织读指的是多线程（进程）读同一个打开的文件描述符，单个线程的顺序读在操作系统看来可能会变成随机读。同样我们还是结合实例来分析。事例代码{ ...... f = open("file", ......)