OmniOS / ZFS / Windows 7:在应用程序中“另存为”时间长度超过CIFS / SMB所有文件大小5秒

情况:

运行OmniOS r151018(95eaa7e)服务器的文件服务器上的一个文件服务器发生以下奇怪的问题,通过SMB到Windows和OS X来宾。

通过SMB共享中的“另存为…”(Save as …)对话窗口保存某些文件(.docx,.xlsx,一些图像)会导致滞后大约3到5秒,应用程序根本没有响应,文件正常保存。

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

一些观察:

  • 它发生在所有Windows 7客户端上
  • 它发生在所有文件大小
  • 它发生在这台机器的所有份额上,不pipe权限如何
  • 在另一台服务器上通过iSCSI从主机上导入的存储速度更快
  • GBit以太网正常复制速度为110 MB / sec
  • 数据和根池似乎没有问题
  • 它不会发生在其他文件服务器上
  • 当文件保存在本地时不会发生,然后通过资源pipe理器复制
  • 它不会在OS X上发生(只能用OpenOffice进行testing)
  • dmesg显示了几条NOTICE: bge0: interrupt: flags 0x0 - not updated? 具有各种价值,但这也是如此,没有任何伤害

更多的理念/计划:

由于没有明确的错误信息可能会被发现,因此我可能需要对原因进行一些反复试验。 我会考虑一些事情( 结果用斜体表示 ):

  • 将Broadcom网卡replace为Intel卡=>没有什么区别
  • 用SATA固态硬盘替代根池(目前SLC内存U盘可以正常工作3年以上) =>没有任何区别
  • 检查两者之间的networking(硬件,通过直接连接到服务器)
  • 使用WireShark进行stream量捕获:如果您不确切知道自己在找什么,就很困难
  • 恢复到以前的OmniOS引导环境/版本以排除软件冲突=>没有什么区别
  • 回滚Windows / Office更新以排除错误
  • 从快照中删除文件名为(冒号)的文件名,由ewwhite =>创build的reddit线程上的txgsync提示没有任何区别

    当Windows“早期版本”function启用包含“:”字符的自动快照时,我看到类似于此的东西。 只需用这个拍摄风,但可能值得一看,因为在Windows文件名中不允许使用“:”字符。

  • 监视文件访问:如shodanshok所build议的,我使用DTrace和此脚本来监视文件访问。 我在保存已读文件时使用了它,删除了无关的输出和个人信息,结果围绕着三个文件:

     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 ),但是在这两种情况下,所有的文件操作都在同一秒进行。 =>没有什么区别

  • 在其他主机上导入磁盘以检查池碎片或磁盘是否有故障=>没有任何区别
  • 将数据和根池移到同一台机器,以排除布线,主板等问题>问题仍然存在,因此必须是根池(软件)或与软件不兼容的特定硬件(或突然变得不兼容。 ..)

你能build议其他什么是这种行为的原因吗? 还是你有类似的经历? 因为我在网上找不到任何有用的东西,我怀疑这是一个奇怪的硬件问题(因为它只限于一台机器),或者是Windows / Office的问题。

  • 我需要关于iscsi + zfs(或ntfs)+ windows 2008集群的build议
  • ZFS - L2ARCcaching设备故障的影响(Nexenta)
  • 删除ZFS文件系统的快照,但没有其他的孩子?
  • ZFS进行脱机备份
  • 将数据从根ZFS移动到子文件系统
  • configuration大量存储的新ZFS服务器的最佳方式是什么?
  • One Solution collect form web for “OmniOS / ZFS / Windows 7:在应用程序中“另存为”时间长度超过CIFS / SMB所有文件大小5秒”

    解:

    这个问题只影响OmniOS r151018,而不是以前的版本。 在omnios-discuss邮件列表上的这个线程完全是关于我的问题,从Geoff引用:

    我看到与Nexenta论坛类似的线程。 opslock似乎有问题。 我禁用了opslock,现在我们很好。

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

    不知道为什么这不是咬人更多。

    所以, biteCount++; 我猜。 这个问题通过应用修复和快速重新启动来解决。

    对未来的教训:在尝试任何故障排除之前,只需使用官方邮件列表上的高级search,因为您的问题很可能已经发生在其他人的机器上。 另外,在查找硬件错误之前,启动一个快速虚拟机以排除任何软件,更新或configuration错误。


    我如何到达那里:

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

    r151018经历了这个问题,r151016工作正常。 我怀疑我没有注意到,在我的第一次testing中,因为我只回滚了r151018上的一些更新,而没有回到早期版本。 我认为这个问题一定比我想象的要长。

    在寻找只能逐一更新软件包的方法时,我查看了邮件列表,并在过去的6个月里search了smb从5月份起,出现了正确的解决scheme/相同的问题。

    服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器.