OmniOS / ZFS / Windows 7：对于CIFS / SMB上的所有文件大小,应用程序内的“另存为”滞后5秒

情况：

在运行OmniOS r151018(95eaa7e)的单个文件服务器上发生以下奇怪问题,该服务器通过SMB向Windows和OS X guest虚拟机提供文件.

通过SMB共享上的“另存为…”对话框窗口保存某些文件(.docx,.xlsx,某些图像)会导致大约3到5秒的延迟,此时应用程序根本没有响应,之后文件正常保存.

问题确实发生在“过夜”,没有对服务器做任何事情,但很难确定确切的日期,因为用户投诉仅在第一次发生后的某个时间出现.重新启动服务器后,镜像根池的一个vdev不可用,但仔细检查没有发现设备上的任何故障,并且它已重新连接到池.问题仍然存在.

一些观察：

>它发生在所有Windows 7客户端上
>它适用于所有文件大小
>它发生在本机的所有共享上,无论权限如何
>它可以通过iSCSI从另一台服务器上导入主机上的更快存储
> GBit以太网的正常复制速度为110 MB /秒
>数据和根池似乎没问题
>它不会发生在其他文件服务器上
>当文件在本地保存,然后通过资源管理器复制时,不会发生这种情况
>它不会发生在OS X上(只能使用OpenOffice进行测试)
> dmesg显示几个注意事项：bge0：中断：标志0x0 – 没有更新？具有各种价值观,但这也是以前的情况并没有造成任何伤害

进一步的想法/计划：

由于没有明确的错误消息,我可能需要进行一些试验和错误搜索原因.我会考虑一些事情(结果用斜体字表示)：

>用Intel卡替换broadcom网卡=>没有什么区别
>用SATA SSD替换根池(目前SLC内存USB棒可以正常工作3年以上)=>没有什么区别
>检查两者之间的网络(硬件,通过直接连接到服务器)
>使用WireShark进行流量捕获：如果您不确切地知道自己在寻找什么,那将很困难
>恢复到以前的OmniOS引导环境/版本以排除软件冲突=>没有什么区别
>回滚Windows / Office更新以排除错误
>从快照中删除文件名中的:(冒号)文件,由ewwhite =>创建的reddit线程上的txgsync建议.没有什么区别

I’ve seen something similar to this when the Windows “prevIoUs versions” feature is enabled with automatic snapshots that include a “:” character. Just shooting at the wind with this,but may be worth a look as the “:” character is not allowed in Windows file names.

>监控文件访问：根据shodanshok的建议,我使用DTrace和this script来监控文件访问.我在保存alread打开文件时使用它,删除了不相关的输出和个人信息,结果围绕三个文件：

cpu ID       FUNCTION:NAME
1   18753    fop_open:entry Open: Workbook
0   18181 fop_create:return Create: temp_1
0   18753    fop_open:entry Open: temp_1
0   18753    fop_open:entry Open: Workbook
0   18753    fop_open:entry Open: Workbook
0   18753    fop_open:entry Open: temp_1
0   18888  fop_rename:entry Rename: Workbook -> temp_2
0   18888  fop_rename:entry Rename: temp_1 -> Workbook
0   18753    fop_open:entry Open: Workbook
0   18753    fop_open:entry Open: temp_2
0   18892  fop_remove:entry Remove: temp_2
0   18753    fop_open:entry Open: Workbook
0   18753    fop_open:entry Open: Workbook

在没有发生问题的另一台服务器上执行相同的过程会产生类似的结果：

cpu ID       FUNCTION:NAME
1   25182 fop_create:return Create: temp_1
1   25750    fop_open:entry Open: temp_1
1   25750    fop_open:entry Open: Workbook
1   25750    fop_open:entry Open: temp_1
1   25750    fop_open:entry Open: Workbook
1   25750    fop_open:entry Open: temp_1
1   25889  fop_rename:entry Rename: Workbook -> temp_2
1   25889  fop_rename:entry Rename: temp_1 -> Workbook
1   25750    fop_open:entry Open: Workbook
1   25750    fop_open:entry Open: temp_2
1   25893  fop_remove:entry Remove: temp_2
1   25750    fop_open:entry Open: Workbook
1   25750    fop_open:entry Open: Workbook
1   25750    fop_open:entry Open: Workbook

我还在脚本中添加了时间戳(walltimestamp),但在这两种情况下,所有文件操作都在同一秒进行. =>没有什么区别
>导入另一台主机上的磁盘以检查池碎片或磁盘是否有故障=>没有什么区别
>将数据和根池移到相同的机器上以排除布线,主板等.=>问题确实存在,因此必须是根池(软件)或与软件不兼容的特定硬件(或突然变得不兼容……)

你能否提出其他可能导致这种行为的原因？或者你有类似的经历吗？因为我在网上找不到任何有用的东西,我怀疑这是一个奇怪的硬件问题(因为它仅限于一台机器)或Windows / Office的问题.

解：

该问题仅影响OmniOS r151018,而不是以前的版本.关于omnios-discuss邮件列表的This thread正是关于我的问题,Geoff引用：

I saw a similar thread with Nexenta forum. There seems to be an issue with opslock. I disabled opslock and we are good Now.

svccfg -s network/smb/server setprop smbd/oplock_enable=false

Not sure why this isn’t biting more people.

所以,biteCount;我猜.通过应用修复程序并快速重新启动解决了该问题.

未来的教训：在尝试任何故障排除之前,只需使用官方邮件列表上的高级搜索,因为很可能您的问题已经发生在其他人的计算机上.此外,在查找硬件错误之前,请启动快速VM以排除任何软件,更新或配置错误.

我是怎么到达那里的：

在更新的问题中看到几个不同的测试后,我将其缩小到特定硬件上的软件问题或硬件/驱动程序冲突.为排除第二种情况,我在另一台主机上安装了两台新的OmniOS虚拟机r151018和r151016,并在每台主机上手动配置了基本的SMB共享.

r151018遇到了问题,r151016工作正常.我怀疑在我的第一次测试中我没有注意到它,因为我只在r151018上回滚了一些更新,而不是回到早期版本.我认为这个问题肯定比我想象的还要长.

在寻找一种只能逐个更新软件包的方法时,我查看了邮件列表并搜索了过去6个月的smb,其中出现了正确的解决方案/同样的问题,可以追溯到5月份.