Ситуация:

Следующая странная проблема возникла на одном файловом сервере под управлением OmniOS r151018 (95eaa7e), обслуживающего файлы через SMB для гостей Windows и OS X.

Сохранение определенных файлов (.docx, .xlsx, некоторых изображений) через диалоговое окно «Сохранить как ...» на общем ресурсе SMB приводит к задержке от 3 до 5 секунд, когда приложение вообще не отвечает, после этого файл сохраняется в обычном режиме.

Проблема действительно возникла «за ночь», без каких-либо действий с сервером, но трудно определить точную дату, поскольку жалобы пользователей поступили только через некоторое время после первого появления. После перезагрузки сервера один виртуальный дескриптор зеркального корневого пула был недоступен, но более тщательный осмотр не обнаружил никаких сбоев на устройстве, и оно было повторно подключено к пулу. Проблема все еще сохраняется.

Некоторые наблюдения:

• Это происходит на всех клиентах Windows 7
• Это происходит для файлов любого размера
• Это происходит на всех общих ресурсах этой машины, независимо от разрешений
• Это происходит для более быстрого хранения, импортированного на хост через iSCSI с другого сервера
• Нормальная скорость копирования составляет 110 МБ / с через GBit Ethernet
• Данные и корневой пул кажутся нормальными
• Этого не происходит на других файловых серверах
• Этого не происходит, когда файл сохраняется локально, затем копируется через проводник
• Этого не происходит в OS X (можно проверить только с помощью OpenOffice)
• dmesg показывает несколько значений ПРИМЕЧАНИЕ: bge0: interrupt: flags 0x0 - not updated? с различными значениями, но так было и раньше, и это не повредило

Дальнейшие идеи / планы:

Поскольку четкого сообщения об ошибке не обнаружено, мне может потребоваться выполнить поиск методом проб и ошибок причина. Некоторые моменты, которые я рассмотрю ( результаты выделены курсивом ):

• Замените сетевую карту Broadcom на карту Intel => ничего не изменилось
• Замените корневой пул на SATA SSD. (в настоящее время USB-накопители SLC, которые отлично работали более 3 лет) => не имело значения
• Проверить сеть между ними (оборудование, путем подключения напрямую к серверу)
• Захват трафика с помощью WireShark: сложно, если вы точно не знаете, что ищете
• Вернитесь к предыдущей загрузочной среде / версии OmniOS, чтобы исключить конфликты программного обеспечения => не имеет значения
• Откат обновлений Windows / Office для исключения ошибок

• Удаление файлов с : (двоеточие) в именах файлов из снимков, предложение txgsync в ветке reddit, созданной ewwhite => ничего не изменилось

  Я видел нечто подобное, когда функция Windows «предыдущие версии» включала автоматические снимки, содержащие символ «:». Просто стреляйте по ветру с этим, но, возможно, стоит взглянуть, поскольку символ ":" не разрешен в именах файлов Windows.

• Мониторинг доступа к файлам: как было предложено shodanshok, я использовал DTrace и этот сценарий для отслеживания доступа к файлам. Я использовал его при сохранении уже открытого файла, удалил несвязанный вывод и личную информацию, и результат сосредоточился вокруг трех файлов:

   CPU ID FUNCTION: NAME
  1 18753 fop_open: entry Open: Рабочая тетрадь
  0 18181 fop_create: return Create: temp_1
  0 18753 fop_open: entry Open: temp_1
  0 18753 fop_open: entry Open: Рабочая тетрадь
  0 18753 fop_open: entry Open: Рабочая тетрадь
  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: Рабочая тетрадь
  0 18753 fop_open: запись открыта: temp_2
  0 18892 fop_remove: запись Удалить: temp_2
  0 18753 fop_open: entry Open: Рабочая тетрадь
  0 18753 fop_open: entry Open: Рабочая тетрадь
  

  Та же процедура на другом сервере, где проблема не возникает, дает аналогичный результат:

   ИДЕНТИФИКАЦИЯ ЦП ФУНКЦИЯ: ИМЯ
  1 25182 fop_create: return Create: temp_1
  1 25750 fop_open: entry Open: temp_1
  1 25750 fop_open: entry Open: Рабочая тетрадь
  1 25750 fop_open: entry Open: temp_1
  1 25750 fop_open: entry Open: Рабочая тетрадь
  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: Рабочая тетрадь
  1 25750 fop_open: запись открыта: temp_2
  1 25893 fop_remove: запись Удалить: temp_2
  1 25750 fop_open: entry Open: Рабочая тетрадь
  1 25750 fop_open: entry Open: Рабочая тетрадь
  1 25750 fop_open: entry Open: Рабочая тетрадь
  

  I also added timestamps (walltimestamp) to the script, but in both cases all file operations take place at the same second. => did not make a difference

• Import disks on another host to check if pool fragmentation or disks are faulty => did not make a difference
• Move data and root pool over to identical machine to rule out cabling, mainboard etc. => problem does persist, so must be either the root pool (software) or a specific hardware that is incompatible with the software (or did suddenly become incompatible...)

Could you suggest anything else that be be the cause of this behavior? Or did you experience something similar? because I could not find anything helpful online, I suspect it is either a strange hardware problem (because it is limited to one machine) or a problem with Windows/Office.