NFS mount本地挂载的一个大坑，可有回避方案？
在文件很大或频繁访问小文件时，会导致极为可观的网络流量，严重时会把网络拖垮。。
【 在 Mikov 的大作中提到: 】
: 这种情况就别用nfs了. 本来nfs就是一种偷懒的做法.
: 在存储端跑一个jvm做代理, 将功能接口化
嗯，在公有云的虚拟IDC里，，，
其实原本想用S3兼容接口的存储服务（比如Minio），不过技术调研还有些兼容性问题。
用NFS是个过渡，还考虑过FTP的方案，但是FTP也是个巨坑。
姑且先用cachefilesd配合NFS试试，只要能降低反复读的压力就能扛一段时间，
等到S3兼容的存储服务OK了，就直接切换到S3 API了。
【 在 zxeoc 的大作中提到: 】
: 文件存进去的时候就同时存一份相关信息，手工维护一下两者的关系
现在就等价于这么干的。
因为文件是用户上传而来的，取得size、mime等信息的时候就改为从上传的临时文件里取了。
不过即便如此，从临时文件到nfs落盘等，有些第三方代码还是不好控制的，导致多读了几次文件。
回来报告一下初步结果：cachefilesd然并卵。
有待进一步调查。
【 在 zxeoc 的大作中提到: 】
: 文件信息存db或者redis之类的地方呢？
嗯，文件信息是有存在DB的，
问题就在于，文件从用户上传到元数据入DB之前，就产生了大量的NFS网络IO。
一个两个文件体现不出来，同时上传成千上万的文件时就很可观了。
【 在 ckc 的大作中提到: 】
: sshfs
新技能get～
先赞后看。：D
不知道sshfs对于大量文件写入的性能怎么样？
比如1000个小文件同时写入。。
【 在 zxeoc 的大作中提到: 】
: 上传文件除了写入本身，还有什么io？如果就是指写入本身，那这个没有什么好办法
除了写入就是获取元数据了，size、mime神马的。
第三方底层代码有点渣（flysystem），不是各种attr在一次access里全部取回，
而是每个attr就access一次，如图，吐血……
第三方代码能改的地方已经改了，目前的情况比图上要好一点，但是对整体IO压力改善不大。
【 在 zxeoc 的大作中提到: 】
: 如果这样的话我建议你换个第三方，这么搞以后换了S3也未必扛得住
: 这让我想起当初写SAP报表，本来被一个跑半小时客户端掉线都跑不出来的报表引发了强迫症，但是看代码看到同事的20多个数据库查询语句写在5重循环里面，强迫症瞬间就治好了
哈哈哈，咱也不能比烂么不是。。：D
flysystem是一个标准，提供一套接口，对于不同的后端存储是不同的实现，烂的是Local的实现（其实只是它没针对远程文件做优化罢了），
S3的实现还是可以的，不过就是S3的API太重了，，代码极其绕……
因为S3依赖HTTP，额外的事就少不了，也不奇怪。
另外我还没有找到一个对S3 API兼容比较好的第三方存储实现，
之前调查过Minio，但是存在兼容性问题，没接着往下调查。
【 在 cn62 的大作中提到: 】
: nfs会有这种问题？
: getattr不会获取文件内容啊。
事实如此咯。。。
特定版本都nfs和kernel凑在一起还会闪崩呢。。
【 在 nikezhang 的大作中提到: 】
: 网上说getattr调用比较多可以调优缓存属性
噢，说的是cachefilesd 吗？
方便的话还请给个url吧。。。
客观地说cachefilesd 确实可以降低最终落到NFS server的压力的，
这一点我在上一次说“然并卵”的时候是不够严谨的，它只是对我遇到的特殊场景帮助不大而已，
但是我用ionotify 反复观察验证过cachefilesd 对于降低文件访问压力是有效的。
我已经改了第三方的实现，把13楼给出的那张图里面每个文件的十余次操作降低为4次，
所有access都消灭了，只留下create、open、modify、close_write、close。
20180416追记：
nfs的问题今天早上还真找到解决办法了。。。
一个底层组件为了控制单一文件夹下的文件数量，每写入一个文件就listdirectory一次（判断已有文件数），
导致nfs readdir的巨大网络开销，现在改成不要自动控制文件数量了，直接预设1024个目录，
按文件名hash分片给1024个目录，这样就算每个文件夹控制到65535，也够6千万+的文件数量，
到时人工监控文件数量，差不多了就改一下文件夹名称的偏移量，自动导流到1024个新目录。。。
nfs readdir 的网络开销，能把上传流量放大100倍，比如网关接收的上传流量只有5Mbps的时候（每个文件几十KB），
存储节点的带宽能占到500Mbps，其中90%的带宽都被readdir操作消耗了，砍掉这部分流量之后就轻松多了。