网络文件系统是否预取?(或者:Internet文件系统是否进行了优化以减少往返行程)

sel*_*bie 5 linux filesystems samba nfs network-protocols

使用以下代码段:

 f = open("/mnt/remoteserver/bar/foo.bin", O_RDONNLY);
 while (true)
 {
       byteseread = read(f, buffer, 1000);
       if (bytesread > 0)
           ProcessBytes(buffer, bytesread);
       else
           break;
  }
Run Code Online (Sandbox Code Playgroud)

如果以上面的示例为例,假设远程文件foo.bin为1MB,并且以前从未被客户端访问过。因此,大约需要进行1000次“读取”调用才能获取整个文件。

此外,假设在客户端上安装了目录的服务器是通过Internet而不是本地的。到客户端的快速带宽,但延迟较长。

是否每个“读取”调用都调用往返服务器的往返请求更多数据?还是客户机/服务器协议识别出远程文件上的后续读取通常是顺序读取的,因此,在应用程序实际对其进行read()调用之前,将后续块下推。因此,由于预取并缓存了数据,因此后续的读取调用返回得更快。

现代网络文件系统协议(NFS,SMB / Samba或其他协议)是否进行了类似的优化。是否有针对互联网优化的网络文件系统协议具有这样的优化?

我正在调查一个个人项目,该项目可能涉及通过Internet实施网络文件系统。令我震惊的是,如果可以减少文件I / O的往返次数,性能可能会更快。

eas*_*sel 3

这将非常依赖于协议实现。一般来说,我不认为大多数客户端实现预取,但大多数精明的存储管理员使用大块大小(32+kb 请参阅 rsize/wsize 挂载选项),这实际上会导致相同的结果。网络文件系统通常也会通过系统缓冲区缓存进行缓存,因此您绝对不会将 read() 调用直接转换为网络 IO。

我的建议是天真地编写程序(或简单的测试用例)并通过 nfsstat 等轻松读取网络统计信息,然后从那里进行优化。变量太多,无法以其他方式得到答案。

我不是专家,但据我所知,NFS4 比旧协议(nfs2、3、cifs)有更多的 WAN 优化,因此我肯定会将其纳入您的组合中。也就是说,大多数远程文件系统协议并不是真正为高延迟访问而设计的,这就是为什么我们最终会使用像 S3 这样的系统。