我们为什么要关注业务的IO行为，或者IO访问模型呢？原因很简单，任何系统都要关注自己服务的对象，存储系统服务的对象就是上层应用，所以存储的研发离不开对业务行为的分析和研究。存储系统的整体设计和架构，是多种因素综合权衡的结果。在存储系统性能达到极限的时候，无论是存储的开发者还是使用者，都想知道IO的具体表现行为，开发者是为了能够找到瓶颈点，更好地优化存储系统，使用者是为了能够更优地使用存储系统，让业务稳定运行。
常见业务类型的IO特点
我们先基于几个典型的业务场景，介绍一下这些场景下IO模型的特点。
记录日志
日志文件通常情况都是追加写入，在每一次写之前，都需要调用statfs获取文件大小，以此作为pos（新内容插入位置）写入数据，因此write和statfs的请求比例是1:1。反过来，如果发现在某个客户端的请求统计中发现，write/stat请求比例接近1:1，基本可以断定，此客户端上的业务基本上是文件的追加写业务。如果面对这种日志IO类型在存储整体访问中占比比较高的用户，在需要提升系统整体性能时，可以建议用户扩大日志文件的写入buffer，从而减少write/stat的请求次数，达到性能优化的效果。
系统命令du/ls
操作系统的几个命令对于分布式文件存储来说，都不是特别友好，比如说ls/du，尤其是du命令。du命令会调用readdir，获取entry列表，再依此调用statfs获取文件size，如果是目录，还会递归查询统计，因此是多个readdir和多个statfs请求的组合，并且穿插调用，对于多MDS架构的文件系统，通常每个MDS都会处理大量readdir和statfs的请求。ls命令也是readdir和stat的组合，但是跟du不同的是，ls只会统计单一目录下的stat信息，因此是一个readdir和多个statfs请求。假如日常巡检的时候发现某个MDS负载较高，可以查看该MDS的负载类型，如果都集中在readdir/statfs，那么基本可以断定，有业务在执行系统统计命令，可以根据请求发送的客户端IP，获取到是哪个客户端发起的请求，进而可以查到是哪个业务触发的系统指令。
数据库
数据库的读写比例一般符合二八原则，20%是写，80%为读，在写的时候，以8KB，16KB为主，并且每一个写请求都会附带一个fsync请求和一个fdatasync请求，用来保证数据持久化到存储上，对于采用buffered cache的分布式文件存储，fsync带来的系统开销会比较大，进而导致数据库的写入性能较差，假如用户有数据业务的需求，建议采用direct IO的方式。MySQL的存储引擎InnoDB中有一项设置——innodb_flush_method，这项设置负责控制InnoDB写入数据时所使用的系统调用。我们会建议用户采用O_DIRECT_NO_FSYNC，即只使用O_DIRECT方式，绕过pagecache，将数据直接写入磁盘，并在写操作时跳过fsync()更新日志的元数据信息。在8.0.14版本之后， MySQL会在创建文件、增加文件长度以及关闭文件时自动调用fsync()来更新MySQL文件在文件系统中的元数据信息。
AI训练
大家都知道，在AI训练过程中，数据90%以上都是读操作，并且是小文件的顺序读或大文件的随机读。在训练过程中，数据集是不会被修改和删除的，元数据的操作集中在open/close/stat/revalidate，不会有特殊的元数据操作，数据操作就是read。基于这种IO特点，当需要进一步提升性能时，可以选择性弱化某些POSIX语义，甚至是降低数据的一致性，比如说在客户端增加弱化一致性之后的读缓存，从而大大提升训练过程中对数据的读取速度，缩短训练时间。
分析业务IO模型的方法
分析业务IO的模型有两种方式，可以通过阅读业务的源码，或者是通过存储系统提供的IO分析工具。然而，阅读业务源码大多数时候并不现实，而且对于存储开发人员或者运维人员，也没有这个必要，所以更多时候，只能依靠存储系统提供的IO分析工具。
在大规模存储系统中，分析业务的IO行为是一套非常复杂的流程，尤其是分布式文件存储，文件存储需要实现一套标准POSIX语义的文件接口，丰富的接口带来的困扰就是需要监控和分析更多的IO操作类型，分析的难度也就更大。对文件存储来说，我们需要关注两类IO，元数据和数据。元数据IO主要包括文件/目录的元数据操作，比如说open/close/mkdir/rmdir/stat/unlink/revalidate/hardlink/rename等，数据IO主要包括read/write，在统计read/write的时候，还要统计对应的IOPS和BW。遗憾的是，市场上常用的文件存储产品和方案也很少提供方便的工具帮助管理员系统地了解业务IO特点。
