- 主题:网络文件系统的一个细节
考虑一下网络文件系统的一个场景。。
我们在命令行里面发出了 rm xxx.txt 这条命令，要求远程文件系统删除文件。
那么，如果 unlink 命令还没发到远程时我们按了 ctrl+c 取消。此时远程没有真正删除。
如果 unlink 命令已经发送到远程，但是此时我们又按 ctrl+c 取消，那么此时，远程到底是删除成功了还是未删除成功呢，陷入一种两端不同步的状态。
NFS 和 SMB 是怎么处理这个问题的呢？
--
FROM 120.33.10.*
就看中止信号发送的及时不及时呗，想象是一个消息队列，这种问题肯定设计之处就考虑到的。
【 在 hgoldfish 的大作中提到: 】
:
: 考虑一下网络文件系统的一个场景。。
:
: 我们在命令行里面发出了 rm xxx.txt 这条命令，要求远程文件系统删除文件。
:
#发自zSMTH-v-@Redmi M2007J17C
--
FROM 36.112.185.*
本端（手动或者自动）refresh一下文件列表就行
--
FROM 123.118.191.*
从server端视角考虑
第一种就是什么指令也没收到 没变化
第二种就是收到了删除 文件删除
什么时候取消server不关注，它只看到自己收到了什么
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 考虑一下网络文件系统的一个场景。。
:
: 我们在命令行里面发出了 rm xxx.txt 这条命令，要求远程文件系统删除文件。
:
--
FROM 101.93.138.*
以对方收到删除消息为准。然后和本地同步状态。如果你中断的真的非常精准到位，那可能的表现是：
rm
ctrl -c
看到本地仍然有文件
看到本地文件消失了
【 在 hgoldfish 的大作中提到: 】
: 考虑一下网络文件系统的一个场景。。
: 我们在命令行里面发出了 rm xxx.txt 这条命令，要求远程文件系统删除文件。
: 那么，如果 unlink 命令还没发到远程时我们按了 ctrl+c 取消。此时远程没有真正删除。
: ...................
--
FROM 117.133.52.*
NFS和SMB不太一样，NFS是无状态，SMB有session管理，
NFS把删除命令发送到server端就完了，
SMB只要挂载的，session就在，即使命令停止了，后面结果也是会更新的
--
FROM 183.195.12.*
有点儿意思。
--
FROM 103.235.150.*
NFS 都只是简单把系统调用提交到服务端吗？那岂不是客户端非常的简单？复杂度主要在服务端？
SMB 的 session 里面有包含目录的内容缓存吗？如果没有的话，它的每次 readdir() 都会转发给服务端吗？
如果客户端都没有目录内容的缓存，会不会日常操作比较慢？
【 在 CongHL 的大作中提到: 】
: NFS和SMB不太一样，NFS是无状态，SMB有session管理，
: NFS把删除命令发送到server端就完了，
: SMB只要挂载的，session就在，即使命令停止了，后面结果也是会更新的
: ...................
--
FROM 110.81.1.*
NFS协议本身也挺简单，服务端也不复杂，主要依赖底层文件系统。
SMB一般是有缓存的，可以通过atime判断是否有更新，有的文件系统考虑性能没有启用atime会用一些其他的类似机制
如果客户端复杂操作比较多，smb性能是好一点，nfs主要赢在协议简单性能好。
【 在 hgoldfish 的大作中提到: 】
: 考虑一下网络文件系统的一个场景。。
:
: 我们在命令行里面发出了 rm xxx.txt 这条命令，要求远程文件系统删除文件。
:
: 那么，如果 unlink 命令还没发到远程时我们按了 ctrl+c 取消。此时远程没有真正删除。
:
: 如果 unlink 命令已经发送到
: ..................
发自「今日水木 on 2106118C」
--
FROM 101.90.3.*
NFSv4也有session概念，不过用v4的不多，v4也没有v3的性能好。
【 在 hgoldfish 的大作中提到: 】
: 考虑一下网络文件系统的一个场景。。
:
: 我们在命令行里面发出了 rm xxx.txt 这条命令，要求远程文件系统删除文件。
:
: 那么，如果 unlink 命令还没发到远程时我们按了 ctrl+c 取消。此时远程没有真正删除。
:
: 如果 unlink 命令已经发送到
: ..................
发自「今日水木 on 2106118C」
--
FROM 101.90.3.*