NFS mount本地挂载的一个大坑，可有回避方案？

当你只需要获取一个文件的attributes，而非整个文件的内容时，它也会将整个文件传输到客户机， 

在文件很大或频繁访问小文件时，会导致极为可观的网络流量，严重时会把网络拖垮。。 

【 在 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操作消耗了，砍掉这部分流量之后就轻松多了。