问题：
使用vdbench进行单层100w目录，每个目录30个文件，共3000w文件读写时，在创建文件得时候IO会出现断断续续得情况。
分析过程：
1、 nfs抓包分析
使用vdbench创建一个文件得流程eg: vdb_f0398.file：
Lookup call -> lookup reply ->create call ->create reply ->write call ->write reply
2、 当vdbench IO归0时，观察存储端状态
1） read IO特别大，write IO为0
看4标识
2） zfs arc到了limit点为，arc_prune数值增加，意味着频繁得回收arc，但arc大小为变化
看上图1是设定的arc_meta_limit，2是已经使用的arc_meta空间，一般触发回收时会高出limit限制几百M，3是回收次数。其在arc_meta使用触发回收时短时间内多次回收调用，但是回收的arc空间很少，之后不再回收，导致arc一直是full的状态。
3） arc相关参数变化
没有释放arc
看图5标识，此处为有写IO时，此时为readdir执行完了一次后，在对应的目录下创建了30个文件（vdbech配置的）。
4） 使用perf分析进程变化情况
发现进程lz4_decompress_zfs 进程变化比较明显
5） 通过dump_stack打印lz4的调用栈：
从打印情况看两个可疑点，出问题的时候zfs_readdir 和 reconnect_path被不停的调用
6） 从这两个地方分析是否存在问题
1》 zfs_readdir其dump_stack情况
分析内部代码，打印事件发现：
会发现while执行的次数和时间会随着目录数的增加线性增长，100w目录查询一次一般会超过10s（8s-180s,当时应该受到arc回收影响，没出现IO归零时不会调用到此函数）
2》 reconnect_path情况
出现问题时，exportfs参数没有收到期望的具体vdb.1_6795.dir目录名，而是根目录/(注意此处设置nfsd thread数为1，默认是32，会进行32次根目录的调用，其造成阻塞的概率增大，并耗时非常长)
由此触发了zfs_readdir
此处引出问题，为什么参数会是根目录？？？？
7） 当arc缓存开始执行回收操作时，出现问题
而多次回收内存并未释放多少，前面图示可以看出。
8） 由上联合起来分析汇总：
当arc使用接近限制阈值的时候，触发回收操作，而回收操作只回收一点，但将原来的目录缓存破坏掉，使用新创建的文件元数据来填充arc，大量的arc缓存无法释放。导致当服务器端nfs执行 lookup确定要创建的文件是否合法时，触发了reconnect_path->zfs_readdir等操作，来进行所有目录的重新匹配，而此时arc已经满了无法缓存，导致接下来的每次lookup都要执行一遍readdir。
此处引出问题，为什么缓存释放不了？？？
3、 由上分析，猜测服务器vdbench缓存了inode，dentry等信息
通过在跑vdbench IO时，观察服务器内存使用情况发现，随着创建文件夹和文件，内存使用明显
尝试在存储端arc接近缓存阈值时，清除服务器的缓存，主要是dentry、inode信息。多次测试发现问题不再重现。Arc可以正常释放，并且释放速度较快。
4、 综上确定问题出现vdbenc IO，在创建文件夹和文件的时候会影响zfs ARC缓存释放，引出问题：
1） vdbench 在没有创建完文件之前会维护这些link？
2） Nfs客户端做的缓存？
3） 此现象对其他公司nas产品是否一样？
4） 需要存储端解决此问题？如何解决？
5、arc小于2G回收会出问题这个大概率是之前的因素影响，还在分析代码并测试中~~。测试了一次1.5G的在服务器端正常释放缓存后，没啥问题。