Ситуация:

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

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

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

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

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

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

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

• Замените сетевую карту Broadcom на карту Intel => ничего не изменилось
• Замените корневой пул на SSD-диски 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
  

  Я также добавил timestamps ( 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 месяцев, где всплыло правильное решение / та же проблема, начиная с мая.