OmniOS / ZFS / Windows 7: «Сохранить как» из приложений отстает на 5 секунд для всех размеров файлов по CIFS / SMB

Ситуация:

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

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

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

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

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

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

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

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

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

Мониторинг доступа к файлам: как подсказал shodanshok, я использовал 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) в скрипт, но в обоих случаях все файловые операции выполняются в одну и ту же секунду. => не имело значения

Импортируйте диски на другой хост, чтобы проверить, нет ли фрагментации пула или дисков => не имело значения
Переместите данные и корневой пул на идентичную машину, чтобы исключить кабели, материнскую плату и т. Д. => проблема не устранена, поэтому должен быть либо корневой пул (программное обеспечение), либо конкретное оборудование, которое несовместимо с программным обеспечением (или внезапно стало несовместимым ...)

Не могли бы вы предложить что-нибудь еще, что могло бы быть причиной такого поведения? Или вы испытывали нечто подобное? поскольку я не смог найти ничего полезного в Интернете, я подозреваю, что это либо странная проблема с оборудованием (потому что она ограничена одним компьютером), либо проблема с Windows / Office.

Решение:

Проблема касается только OmniOS r151018, но не предыдущих версий. Эта ветка в списке рассылки omnios-обсуждения была именно моя проблема, цитата из Джеффа:

Я видел похожую ветку на форуме Nexenta. Кажется, проблема с opslock. Я отключил opslock, и теперь у нас все хорошо.

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

Не уверен, почему это не кусает больше людей.

Так, biteCount++; Я думаю. Проблема была решена применением исправления и быстрой перезагрузкой.

Уроки на будущее: перед попыткой устранения неполадок просто воспользуйтесь расширенным поиском в официальных списках рассылки, поскольку, скорее всего, ваша проблема уже возникла на чужом компьютере. Кроме того, перед поиском ошибок оборудования быстро разверните виртуальную машину, чтобы исключить любые ошибки программного обеспечения, обновлений или конфигурации.

Как я туда попал:

После нескольких различных тестов, как показано в обновленном вопросе, я сузил его до программных проблем или конфликтов оборудования / драйверов на конкретном оборудовании. Чтобы исключить второе, я установил две свежие виртуальные машины OmniOS, r151018 и r151016 на другом хосте и вручную настроил базовый общий ресурс SMB на каждой из них.

На r151018 возникла проблема, r151016 работает нормально. Я подозреваю, что не заметил этого в своих самых первых тестах, потому что я откатил только некоторые обновления на r151018, а не на более раннюю версию. Думаю, проблема существовала дольше, чем я предполагал.

Когда я искал способ обновлять пакеты только один за другим, я просмотрел список рассылки и искал smb за последние 6 месяцев, когда появилось правильное решение / та же проблема, датируется мая.