在本文中我将引用五篇有关disk io 的好文章来与读者一起学习探讨关于磁盘IO的事。我大概会提取一些关键点，如果你不太理解或想要深入，不要错过那些链接哦。当然任何文章都不要盲信，不肯定时就要多方论证。
on disk io, part 1
network io 被关注得多，disk io关注得少，部分原因在于network io 有许多特性和不同的实现，而disk(或file system) io只是很少一部分工具子集
sector是块设备的最小传输单元；文件系统最小可寻址单元是block，block是相邻的sector的组合；IO是虚拟内存来操作，它会缓存block在buffer中，虚拟内存操作的是page，它会被映射到block (https://superuser.com/a/350499 这个答案解释得不错，文件系统的block理解为logical block)
读时先查看page cache，如果没有则page in；写时先写到page cache，等合适时再flush
关于DIRECT IO
有些时候不想通过page cache写disk，可能出于效率原因，可以通过指定O_DIRECT来绕过page cache直接写块设备。设计合理的话可以提供更加细粒度的IO控制，应用端常需有自己的cache layer
我详细查看了作者引用的关于Linus在linux kernel新闻组的回复，他说：
- O_DIRECT特别适用于诸如database的应用，若能支持异步则会更好
- Linus认为O_DIRECT接口设计很糟糕，提供了一种比它更好的two-phases way(顺便吐槽了一下database设计者没有好的设计品味)
- 使用AIO是非常好的，但它只是为了掩盖糟糕的设计；倘若接口设计良好不用AIO也是可以的
像mysql, postgresql也是使用了O_DIRECT的，比如pg用于写WAL；同时开启O_DIRECT和page cache当然是不推荐的；
如果要进行direct IO,则需保证io starting address 和io size必须与block大小保持对齐; 无论是否使用direct IO,保持读写时的地址和大小对齐是个好习惯，减少kernel的额外工作
底下有评论说：
对于压缩和序列化操作，用direct io 和user caching要比OS本身的page cache要好
buffer cache和page cache不是一回事 ？ 这还有待资料验证
关于nonblock
O_NONBLOCK选项不适用于regular filesNon-blocking I/O with regular files，因为文件系统操作本身就是非阻塞的，所以像select,poll也不适合监控普通文件状态
其它参考
fflush是针对于FILE*,将数据从用户层推到OS层，fsync是针对于fd的，将数据推到持久设备上
/dev/raw设备的访问默认是O_DIRECT
O_SYNC/O_DSYNC还会同步写文件的metadata ?
对于新创建的文件，fsync不仅仅是针对于文件还针对于存放这个文件的目录；
为避免覆盖旧数据系统故障导致数据丢失，可以先写temp file，fsync后，再rename，再fsync directory
write/fflush等调用可能并不报IO error，因为数据还在page cache，但fsync,msync,close时则会出现io error，此时对这些调用的返回值是有必要的；
一些文件系统支持在mount指定是否要flush的选项；
**评论值得一看**
part 2, more flavours of io
mmap
文件内容不是立即调入内存的，采用的是延迟加载的形式，因此第一次访问时会有page fault. 使用MAP_POPULATE可强制read ahead
内存映射是通过page cache来实现；
对mmapped 文件的随机访问就和普通指针一样，只不过没有lseek操作
mmap的缺陷：
- 内核要维护相应的数据结构
- mapped files大小有限制
如果要随机访问，有保留很长时间，用mmap，如果是顺序读取，读完了丢弃使用read；最后谁用起来简单用谁
page cache优化
fadvise可提供kernel合适的建议，以提高性能。比如如果要顺序读取文件，可以在真正读取之前用它告诉kernel 提前预读；
mlock可以锁住page，但要慎用以防耗尽内存
aio
glibc并未shipped，需单独安装libaio才能使用；
与O_DIRECT配合使用，不支持buffered io
与posix aio不是一回事，后者是user space aio；
vectored io
可以读small chunks, 减少了系统调用数，且保持了读写原子性；
很少通用型数据库使用vectored io，毕竟它们要处理很多文件，关注延时，cache block-wise，而分析型或列式数据库比较适合使用vectored io，可以并行读入大量数据
目前的方式都有其内在的模式，比如使用O_DIRECT你可能要创建buffer cache，使用page cache需要用到fadvise，使用aio需要用到future-like的接口（指的就是epoll 的回调函数在事件ready后被调用)
On Disk IO, Part 3: LSM Trees
immutable的好处在于不用为数据保留额外空间以防更新成更大的数据；减少了竞争与锁；
immutable/mutable都需要做housekeeping，immutable需要跟踪生成的文件定期做merge，mutable需要减少碎片化
各种DB在LSM的实现上有相似点，都有sorted string table;
sstable就是一个持久化的、有序的、不可变的数据结构，分为data区和索引区；
写都先到内存中的数据结构如skiplist/b-tree，到了一定大小或一定时间就flush到磁盘上成为sstable;
前面的值被后面的update所删除或者写入了新值，称old value is shadowed by new value;
LSM这种设计，在高写负载情况下是可能有高延时的；CPU和磁盘IO可能被Flush,compaction所占满；
有写放大现象；
part 4, b-tree
关于b-tree笔者已经比较熟悉了，但这篇文章还是贴出来，人家都讲得挺好，就不多说了。推荐这篇论文
网友评论