Sytuacja:

Następujący dziwny problem wystąpił na pojedynczym serwerze plików z systemem OmniOS r151018 (95eaa7e) obsługującym pliki przez SMB dla gości Windows i OS X.

Zapisanie niektórych plików (.docx, .xlsx, niektóre obrazy) w oknie dialogowym „Zapisz jako ...” w udziale SMB powoduje opóźnienie około 3 do 5 sekund, w którym aplikacja w ogóle nie reaguje, a następnie plik jest zapisywany normalnie.

Problem pojawił się „w nocy”, nie robiąc nic na serwerze, ale trudno jest ustalić dokładną datę, ponieważ skargi użytkowników pojawiły się dopiero po pewnym czasie. Po ponownym uruchomieniu serwera jeden wirtualny serwer lustrzanej puli głównej był niedostępny, ale dokładniejsza inspekcja nie wykryła żadnych błędów na urządzeniu i została ponownie podłączona do puli. Problem nadal występuje.

Niektóre spostrzeżenia:

• Dzieje się tak na wszystkich klientach Windows 7
• Dzieje się tak dla wszystkich rozmiarów plików
• Dzieje się tak na wszystkich udziałach tego komputera, niezależnie od uprawnień
• Dzieje się tak w celu szybszego przechowywania danych importowanych na hoście przez iSCSI z innego serwera
• Normalna prędkość kopiowania wynosi 110 MB / s przez GBit Ethernet
• Dane i pula root wydają się być w porządku
• Nie dzieje się to na innych serwerach plików
• Nie dzieje się tak, gdy plik jest zapisywany lokalnie, a następnie kopiowany przez Eksploratora
• Nie dzieje się to w systemie OS X (można to przetestować tylko za pomocą OpenOffice)
• dmesgpokazuje kilka obliczeń NOTICE: bge0: interrupt: flags 0x0 - not updated?z różnymi wartościami, ale miało to również miejsce wcześniej i nie wyrządziło szkody

Dalsze pomysły / plany:

Ponieważ nie można znaleźć wyraźnego komunikatu o błędzie, być może będę musiał przeprowadzić próbę i wyszukiwanie błędów. Kilka rzeczy, które rozważę ( wyniki są napisane kursywą ):

• Zastąpienie karty sieciowej Broadcom kartą Intel => nie miało znaczenia
• Zastąp pulę główną dyskami SATA SSD (obecnie pamięci USB SLC, które działały dobrze przez ponad 3 lata) => nie zrobiło różnicy
• Sprawdź sieć pomiędzy (sprzęt, poprzez bezpośrednie połączenie z serwerem)
• Przechwytywanie ruchu za pomocą WireShark: trudne, jeśli nie wiesz dokładnie, czego szukasz
• Powróć do poprzedniego środowiska / wersji rozruchowej OmniOS, aby wykluczyć konflikty oprogramowania => nie miało znaczenia
• Cofnij aktualizacje Windows / Office, aby wykluczyć błędy

• Usuń pliki z :(dwukropkiem) w nazwach plików z migawek, sugestia txgsync w wątku reddit utworzonym przez ewwhite => nie zrobiła różnicy

  Widziałem coś podobnego do tego, gdy funkcja „poprzednich wersji” systemu Windows jest włączona z automatycznymi migawkami zawierającymi znak „:”. Po prostu strzelasz z tym wiatrem, ale może warto spojrzeć, ponieważ znak „:” nie jest dozwolony w nazwach plików Windows.

• Monitorowanie dostępu do plików: jak sugeruje shodanshok, kiedyś DTracei ten skrypt do monitorowania dostępu do plików. Użyłem go podczas zapisywania już otwartego pliku, usunąłem niepowiązane dane wyjściowe i dane osobowe, a wynik koncentruje się wokół trzech plików:

  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
  

  Ta sama procedura na innym serwerze, na którym problem nie występuje, daje podobny wynik:

  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
  

  Dodałem także walltimestampdo skryptu znaczniki czasu ( ), ale w obu przypadkach wszystkie operacje na plikach odbywają się w tej samej sekundzie. => nie zrobił różnicy

• Zaimportuj dyski na innym hoście, aby sprawdzić, czy fragmentacja puli lub dyski są wadliwe => nie zrobiło różnicy
• Przenieś dane i pulę główną na identyczną maszynę, aby wykluczyć okablowanie, płytę główną itp. => Problem nadal występuje, więc musi to być pula główna (oprogramowanie) lub określony sprzęt, który jest niezgodny z oprogramowaniem (lub nagle stał się niezgodny. ..)

Czy możesz zasugerować coś innego, co może być przyczyną tego zachowania? A może doświadczyłeś czegoś podobnego? ponieważ nie mogłem znaleźć niczego pomocnego w Internecie, podejrzewam, że jest to albo dziwny problem sprzętowy (ponieważ jest ograniczony do jednego komputera), albo problem z Windows / Office.

Rozwiązanie:

Problem dotyczy tylko OmniOS r151018, a nie poprzednich wersji. Ten wątek na liście dyskusyjnej Omnios dotyczył dokładnie mojego problemu, cytat z Geoffa:

Podobny wątek widziałem na forum Nexenta. Wygląda na to, że jest problem z opslockiem. Wyłączyłem opslock i jesteśmy teraz w porządku.

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

Nie jestem pewien, dlaczego to nie gryzie więcej ludzi.

Tak biteCount++;myślę. Problem został rozwiązany przez zastosowanie poprawki i szybkie ponowne uruchomienie.

Lekcje na przyszłość: przed przystąpieniem do rozwiązywania problemów wystarczy skorzystać z wyszukiwania zaawansowanego na oficjalnych listach mailowych, ponieważ najprawdopodobniej problem wystąpił już na komputerze innej osoby. Uruchom także szybką maszynę wirtualną, aby wykluczyć wszelkie błędy oprogramowania, aktualizacji lub konfiguracji, zanim zaczniesz szukać błędów sprzętowych.

Jak się tam dostałem:

Po kilku różnych testach, jak widać w zaktualizowanym pytaniu, zawęziłem go do problemów programowych lub konfliktów sprzętowych / sterowników na konkretnym sprzęcie. Aby wykluczyć drugi, zainstalowałem dwie nowe maszyny wirtualne OmniOS, r151018 i r151016 na innym hoście i ręcznie skonfigurowałem podstawowy udział SMB na każdym z nich.

R151018 napotkał problem, r151016 działa dobrze. Podejrzewam, że nie zauważyłem tego podczas moich pierwszych testów, ponieważ przywróciłem tylko niektóre aktualizacje na r151018, a nie poprzedniej wersji. Myślę, że problem musiał istnieć dłużej, niż się spodziewałem.

Szukając sposobu na aktualizację pakietów tylko jeden po drugim, spojrzałem na listę mailingową i szukałem smbod ostatnich 6 miesięcy, gdzie pojawiło się prawidłowe rozwiązanie / ten sam problem, datowane od maja.