NFS缓存IO机制
NFS的缓存IO机制
<一> async 参数模式下分析
NFS 默认的mount参数为async，async 参数表示内核不会透传程序的IO请求给sever,对于写IO会延迟执行，积累一定的时间以便合并上层的IO请求以提高效率。
读分析
1: 顺序读请求的合并预读
dd if=/mnt/nfs/3 of=/dev/null bs=1500 count=100
测试发现仅仅发送了6个read请求 16384 + 32768 * 4 + 2544 =150000，并且其中后5个请求是连续发送的。
2：随机读读惩罚
随机读情况下，由于都有预读，所有每次预读都会多读一部分数据，导致可能实际使用的数据量不到接受到数据的10分之一，称为读惩罚。
写分析
1：追加写
dd if=/dev/zero of=/mnt/nfs/ddtest bs=1 count=100
dd将已经存在的文件的size（SETATTR）设置为0,然后从头开始追加写入这个文件，每次写1B，写100次。但是内核并没有像NFS服务器发送100次写，实际上指发送了一次写。
2：覆盖写
连续覆盖写:内核行为和追加写一样，内核对写操作进行了合并。
随机覆盖小:随机模式下，内核无法对写进行合并，直接完全透传用户程序发起的I/O。
<二> sync参数模式下的分析
读分析
1：如果mount的时候选用sync参数，或者如果上层使用 sync 调用，那么其产生的读I/O一定在内核处也是同步的，因为只有在前一个读请求数据成功返回给客户端程序，客户端程序才会发起下一个读请求，（对于异步读调用，内核可以在短时间内接受到多个读请求，此时内核可以将这些读请求合并，这就是异步过程）。但是同步读并不影响nfs的预读，比如
dd if=/mnt/nfs/ddtest bs=1 count=150,并不是向server发送150个一次1B的请求，而是根据rsize进行预读，把150B的数据一次性读回来，其他159次就直接命中缓存了。
写分析
1：对于sync同步的写调用，程序只有在第一个写调用结束之后才会发起下一个写。
dd if=/dev/zero of=/mnt/nfs/ddtest bs=1 count=1500 (1B为单位的写操作)，那么就是发送150个write请求，效率非常低下。
注意：DIO模式由于每次都绕过了内核的pagecache ，所以每一个请求都会向服务端发起请求，不会进行预读，异步写，写合并，读合并等策略。
https://blog.csdn.net/ta_nk/article/details/7172845
最新文章
- JavaScript权威指南 - 对象
- AutoMapper的使用
- C++ 11 lambda
- Nodejs - windows的系统变量（环境变量）
- PowerMock.expectNew(Class<T> type, Class<?>[] parameterTypes, Object... arguments)
- Centos环境下部署游戏服务器－常用命令
- keil采用C语言模块化编程时全局变量、结构体的定义、声明以及头文件包含的处理方法
- java内存管理简析
- js 一些基础的理解
- [OutLook]关闭Outlook时最小化
- DRF 认证、权限、限制
- day 41 标准文档流 浮动
- 持续集成一：git上传代码
- export，import ，export default区别
- gh-ost：不一样的在线表结构变更
- 快速阅读《QT5.9 c++开发指南》2
- 全网最全的Windows下Anaconda2 / Anaconda3里Python语言实现定时发送微信消息给好友或群里（图文详解）
- 『cs231n』作业3问题3选讲_通过代码理解图像梯度
- QT4.8.5 QComboBox 增加选择菜单记录
- MSP430的CAN通信发送