Durum:

SMN üzerinden Windows ve OS X misafirlerine dosya sunan OmniOS r151018 (95eaa7e) çalıştıran tek bir dosya sunucusunda aşağıdaki garip sorun oluştu.

Belirli dosyaları (.docx, .xlsx, bazı resimler) bir SMB paylaşımındaki "Farklı kaydet ..." iletişim penceresinden kaydetme, uygulamanın yanıt vermediği yaklaşık 3 ila 5 saniyelik bir gecikmeyle sonuçlanır. dosya normal şekilde kaydedilir.

Sorun sunucuya hiçbir şey yapmadan "gece boyunca" meydana geldi, ancak kullanıcı şikayetleri sadece ilk olaydan bir süre sonra geldiğinden kesin tarihi belirlemek zordur. Sunucunun yeniden başlatılmasından sonra, yansıtılmış kök havuzunun bir vdev'i kullanılamaz, ancak daha yakından inceleme cihazda herhangi bir hata bulamadı ve havuza yeniden bağlandı. Sorun hala devam ediyor.

Bazı gözlemler:

• Tüm Windows 7 istemcilerinde olur
• Tüm dosya boyutları için olur
• İzinlerden bağımsız olarak bu makinenin tüm paylaşımlarında olur
• Başka bir sunucudan iSCSI üzerinden ana bilgisayara aktarılan daha hızlı depolama için olur
• GBit Ethernet üzerinden normal kopyalama hızı 110 MB / sn'dir
• Veri ve kök havuzu iyi görünüyor
• Diğer dosya sunucularında olmaz
• Dosya yerel olarak kaydedildikten sonra explorer üzerinden kopyalandığında gerçekleşmez
• OS X'te gerçekleşmez (yalnızca OpenOffice ile test edebilir)
• dmesgNOTICE: bge0: interrupt: flags 0x0 - not updated?çeşitli değerlerle birkaç sayım gösterir , ancak bu daha önce de vardı ve zarar vermedi

Diğer ideads / planlar:

Bulunacak net bir hata mesajı olmadığından, nedenini araştırmak için bazı deneme ve hata yapmam gerekebilir. Dikkate alacağım bazı şeyler ( sonuçlar italik yazılmıştır ):

• Broadcom ağ kartını Intel kart ile değiştirin => bir fark yaratmadı
• Kök havuzunu SATA SSD'lerle değiştirin (şu anda 3 yıl boyunca iyi çalışan SLC bellek USB çubukları) => bir fark yaratmadı
• Arasındaki ağı kontrol edin (donanım, doğrudan sunucuya bağlanarak)
• WireShark ile trafik yakalama: tam olarak ne aradığınızı bilmiyorsanız zor
• Yazılım çakışmalarını ekarte etmek için önceki OmniOS önyükleme ortamına / sürümüne dönme => bir fark yaratmadı
• Hataları dışlamak için Windows / Office güncellemelerini geri alma

• :Dosya adlarında (iki nokta üst üste) bulunan dosyaları anlık görüntülerden kaldırın, ewwhite => tarafından oluşturulan reddit iş parçacığında txgsync tarafından önerilen bir fark yaratmadı

  Windows "önceki sürümleri" özelliği bir ":" karakteri içeren otomatik anlık görüntülerle etkinleştirildiğinde buna benzer bir şey gördüm. Sadece bununla rüzgârda çekim yapmak, ancak Windows dosya adlarında ":" karakterine izin verilmediği için bir göz atmaya değer olabilir.

• Dosya girişin kontrol: shodanshok önerdiği gibi, kullandığım DTraceve bu komut dosya erişimi izlemek için. Tüm açık dosyayı kaydederken, ilgisiz çıktı ve kişisel bilgileri kaldırırken kullandım ve sonuç üç dosya etrafında toplandı:

  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
  

  Sorunun oluşmadığı başka bir sunucuda aynı yordam benzer bir sonuç verir:

  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
  

  Ayrıca walltimestampbetiğe timestamps ( ) ekledim , ancak her iki durumda da tüm dosya işlemleri aynı saniyede gerçekleşiyor. => fark yaratmadı

• Havuz parçalanması veya disklerin hatalı olup olmadığını kontrol etmek için başka bir ana bilgisayarda diskleri içe aktarın => bir fark yaratmadı
• Kablolama, anakart vb . ..)

Bu davranışın nedeni olabilecek başka bir şey önerebilir misiniz? Yoksa benzer bir şey yaşadın mı? çevrimiçi yararlı bir şey bulamadığım için, bunun garip bir donanım sorunu (bir makine ile sınırlı olduğu için) veya Windows / Office ile ilgili bir sorun olduğundan şüpheleniyorum.

Çözüm:

Sorun yalnızca önceki sürümleri değil, OmniOS r151018'i etkiler. Bu iş parçacığı üzerinde liste Geoff benim problem, alıntı hakkında tam olarak posta omnios-tartışmak:

Nexenta forumu ile benzer bir konu gördüm. Opslock ile ilgili bir sorun var gibi görünüyor. Opslock'u devre dışı bıraktım ve şimdi iyiyiz.

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

Bunun neden daha fazla insanı ısırmadığından emin değilim.

Yani, biteCount++;sanırım. Sorun düzeltmeyi uygulayarak ve hızlı bir yeniden başlatma yaparak çözüldü.

Gelecek için dersler: herhangi bir sorun giderme girişiminde bulunmadan önce, resmi posta listelerinde gelişmiş aramayı kullanmanız yeterlidir, çünkü büyük olasılıkla sorununuz zaten bir başkasının makinesinde meydana gelmiştir. Ayrıca, donanım hatalarını aramadan önce herhangi bir yazılım, güncelleme veya yapılandırma hatasını ekarte etmek için hızlı bir VM açın.

Oraya nasıl geldim:

Güncellenmiş soruda görüldüğü gibi birkaç farklı testten sonra, bunu yazılım sorunlarına veya belirli donanımdaki donanım / sürücü çakışmalarına daralttım. İkincisini ekarte etmek için, başka bir ana bilgisayara r151018 ve r151016 olmak üzere iki yeni OmniOS sanal makinesi kurdum ve her birine temel bir SMB paylaşımı elle yapılandırdım.

R151018 sorunu yaşadı, r151016 iyi çalışıyor. İlk testlerimde fark etmediğimden şüpheleniyorum, çünkü daha önceki bir sürüme geri dönmek için değil sadece r151018'de bazı güncellemeleri geri aldım. Bence problem, tahmin ettiğimden daha uzun süredir var olmalıydı.

Paketleri tek tek güncellemenin bir yolunu ararken, posta listesine baktım ve smbMayıs ayından itibaren doğru çözümün / aynı sorunun ortaya çıktığı son 6 aydan itibaren aradım .