文件系统的概念模型

应用程序往一个文件写一段文本或字符串的时候，它会经过系统调用，一经过系统调用，就会从用户空间转变为内核空间 ，系统调用调用的是一个虚拟文件系统的接口，虚拟文件系统是操作系统为了屏蔽底层文件系统的不同实现的做的这么一套东西。

虚拟文件系统在往磁盘上真正的读写数据的时候，会经过一个页缓存，读写都会经过页缓存。拿写文件举例，写的数据，先是写在了缓存里面，等积累到一定的时候，会有一个进程刷到磁盘上面去，而真正往磁盘上面去写数据的时候，又会经过一个缓冲区 buffer，这个也是我们通过top命令去看内存中的buffer/cache里面的那个buffer的值，通过缓冲区buffer后才会真正的写到本地磁盘设备上。

应用层写数据写到pagechace里面，然后vfs虚拟文件系统把page cache里面的数据刷到磁盘io（即磁盘设备这一层）。

虚拟文件系统也可以不经过page cache直接的将数据传到block layer这一层，这种写文件的方式被称作直接io，当直接io请求达到了阻塞io这一层之后，会有一个io的调度程序，在调度之后，会真正的写入到磁盘上去。

那这个调度程序其实是一个将io请求依次排队的一个队列，然后调度这个队列里面的每个io去进行每个io的读写操作。

直接io和裸io区别

• 直接io

直接io是经过文件系统但不经过page cache，直接io的一个比较常见的用法就是在备份文件的时候会用直接io，这样它不会污染文件系统的cache，造成缓存命中率的下降。因为如果在备份数据量很大的文件的时候，经过文件系统页缓存之后，可能会缓存住大量的备份文件，大量的备份文件对应用程序（对外服务的应用程序）是没有起到缓存作用，会造成文件系统的缓存命中率下降。

• 裸io

裸io是绕过了文件系统直接操作磁盘，数据库实际上就是裸io ，因为它不需要经过文件系统的cache那一层，也不需要经过文件系统传递，它能够自己去保存这种读取到的内存资源。

有了整个文件系统的概念模型之后，我们再来分析io的性能问题，如何去衡量整个系统的io性能，我们先从整体上看，再看具体的进程。

从整体上看io的性能，可以通过vmstat或top命令，首先看cache buffer的值，如果过低的话，会造成文件系统的缓存命中率降低，表现可能就是整个系统延迟很高，因为没有命中到内存里面的缓存，而是直接读磁盘的操作会导致系统延迟会大大的增长。

top可以看一个cpu wait值，代表cup在等待执行的时间，这个时间过长了，也是从侧面能够去反映出整个系统阻塞时间过长。

阻塞的原因很有可能是在读写磁盘这种操作造成的阻塞，所以具体还要去看具体是不是磁盘io导致这种问题，

yum install sysstat

iostat -x

所以接下里会用到iostat的这个命令 iostat -x，这个命令是能够以扩展的模式去看整个io的情况，它能暴露出更多的io性能的指标，可以看io的使用率，还有它的一个饱和度。

io使用率平时在用这个工具的时候，第一眼看的其实是这个百分号util这个值，这个指使用率的大小 ，100%也不能说明整个系统的使用率完全处于饱和的状态，因为现在的磁盘io的话，一般都是多通道了，一个通道100%，多通道100好几百才能够到达它的一个使用率的瓶颈，所以如果io有使用率，只能说明你的磁盘是一直在使用的过程当中，是频繁的在进行这种磁盘的操作。

然后要看的另外一个指标就是一个wait，就是一个io请求平均处理的一个时间，如果是响应时间过长的话，那肯定是说明io延迟是过高的，还有一个要关注的一个点就是io请求队列的大小，正常情况肯定是越短越好，如果是过长的话，说明有更多的io请求在排队，可能整个系统已经来不及处理那么多的io请求，会导致系统属于一种延迟的状态。

从进程的角度再看下， 有一个命令叫iotop

，iotop能够列出从大到小io使用率的一个进程列表，从而定位到使用率最高的一个进程，那定位到具体进程之后，还得找出进程是哪一块代码导致了这个使用率过高，在golang程序里面，go trace工具其实是能够去看系统调用产生的延迟。从操作系统的层面，发现了整个系统的一个io的使用率 还有饱和度过高并且定位到了这时候io使用率过高的一个进程，那此时很有可能整个进程因为这种高使用率的这种io操作导致它的延迟性增长。

go trace是能够分析出系统调用的一次io的读取操作，是会被纳入系统调用。

所以通过go trace是能够百分之八九十确定出是哪一段代码在消耗系统调用在进行频繁的io操作。

yum install strace

strace -p pid

Linux下有什么真正断电可靠的文件系统？ - 知乎 (zhihu.com)