Ситуація:
Наступна дивна проблема виникла на одному файловому сервері, на якому працює OmniOS r151018 (95eaa7e), який обслуговує файли через SMB для гостей Windows та OS X.
Збереження певних файлів (.docx, .xlsx, деяких зображень) через діалогове вікно "Зберегти як ..." на SMB-спільному доступі призводить до відставання приблизно від 3 до 5 секунд, де програма взагалі не реагує, після цього файл зберігається нормально.
Проблема сталася «за ніч», не роблячи нічого з сервером, але важко визначити точну дату, оскільки скарги користувачів надійшли лише через деякий час після першого появи. Після перезавантаження сервера один vdev дзеркального кореневого пулу був недоступний, але при більш детальному огляді не виявлено жодних несправностей на пристрої, і він був повторно приєднаний до пулу. Проблема все ще зберігається.
Деякі зауваження:
- Це відбувається у всіх клієнтів Windows 7
- Це відбувається для всіх розмірів файлів
- Це відбувається на всіх акціях цієї машини, незалежно від дозволів
- Це відбувається для швидшого зберігання, імпортованого на хості через iSCSI з іншого сервера
- Нормальна швидкість копіювання становить 110 Мб / сек через GB Ethernet
- Дані та кореневий пул здаються нормальними
- На інших файлових серверах цього не відбувається
- Це не відбувається, коли файл зберігається локально, а потім копіюється через провідник
- Це не відбувається в OS X (можна було протестувати лише OpenOffice)
dmesgпоказує кілька підрахунківNOTICE: bge0: interrupt: flags 0x0 - not updated?з різними значеннями, але це було і раніше, і не завдало шкоди
Подальші ідеї / плани:
Оскільки чіткого повідомлення про помилку не знайдено, мені може знадобитися зробити пробний і помилковий пошук причини. Я буду враховувати деякі речі ( результати вказані курсивом ):
- Заміна мережевої картки Broadcom на карту Intel => не змінила значення
- Замініть кореневий пул на SATA SSD (в даний час USB-накопичувачі пам'яті SLC, які добре працювали протягом 3 років) => не змінили значення
- Перевірте мережу між собою (апаратно, підключившись безпосередньо до сервера)
- Захоплення трафіку за допомогою WireShark: важко, якщо ви не знаєте, що саме шукаєте
- Поверніться до попереднього завантажувального середовища / версії OmniOS, щоб виключити конфлікти програмного забезпечення => не змінилося
- Відмовляйте оновлення Windows / Office, щоб виключити помилки
Видалення файлів із
:(двокрапкою) у назви файлів зі знімків, пропозиція txgsync на потоці reddit, створеній ewwhite =>, не змінила значенняЯ бачив щось подібне до цього, коли функція Windows "попередніх версій" увімкнена автоматичними знімками, що містять символ ":". Просто стріляйте на вітер із цим, але, можливо, варто поглянути, оскільки символ ":" заборонений у назвах файлів Windows.
Моніторинг доступу до файлів: як запропонував shodanshok, я використовував
DTraceі цей скрипт для контролю доступу до файлів. Я використовував це під час збереження відкритого файлу 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.