Situation:

L'étrange problème suivant s'est produit sur un serveur de fichiers unique exécutant OmniOS r151018 (95eaa7e) servant des fichiers via SMB aux invités Windows et OS X.

L'enregistrement de certains fichiers (.docx, .xlsx, certaines images) via la fenêtre de dialogue "Enregistrer sous ..." sur un partage SMB entraîne un décalage d'environ 3 à 5 secondes, où l'application ne répond pas du tout, après quoi le le fichier est enregistré normalement.

Le problème s'est produit "pendant la nuit", sans rien faire pour le serveur, mais il est difficile de déterminer la date exacte, car les plaintes des utilisateurs ne sont arrivées que quelque temps après la première occurrence. Après un redémarrage du serveur, un vdev du pool racine en miroir n'était pas disponible, mais une inspection plus approfondie n'a trouvé aucun défaut sur le périphérique et il a été réattaché au pool. Le problème persiste toujours.

Quelques observations:

• Cela se produit sur tous les clients Windows 7
• Cela arrive pour toutes les tailles de fichiers
• Cela se produit sur tous les partages de cette machine, quelles que soient les autorisations
• Cela se produit pour un stockage plus rapide importé sur l'hôte via iSCSI à partir d'un autre serveur
• La vitesse de copie normale est de 110 Mo / s sur GBit Ethernet
• Les données et le pool racine semblent bien
• Cela ne se produit pas sur d'autres serveurs de fichiers
• Cela ne se produit pas lorsque le fichier est enregistré localement, puis copié via l'explorateur
• Cela ne se produit pas sur OS X (ne pouvait le tester qu'avec OpenOffice)
• dmesgmontre plusieurs chefs d'accusation NOTICE: bge0: interrupt: flags 0x0 - not updated?avec différentes valeurs, mais c'était également le cas auparavant et n'a fait aucun mal

Autres idées / plans:

Comme il n'y a pas de message d'erreur clair à trouver, je devrais peut-être faire des essais et des erreurs pour rechercher la cause. Certaines choses que je considérerai (les résultats sont en italique ):

• Remplacer la carte réseau Broadcom par une carte Intel => n'a pas fait de différence
• Remplacez le pool racine par des SSD SATA (actuellement des clés USB à mémoire SLC qui ont bien fonctionné pendant plus de 3 ans) => n'a pas fait de différence
• Vérifiez le réseau entre les deux (matériel, par connexion directe au serveur)
• Capture de trafic avec WireShark: difficile si vous ne savez pas exactement ce que vous recherchez
• Revenir à un environnement / version de démarrage OmniOS précédent pour exclure les conflits logiciels => n'a pas fait de différence
• Annulez les mises à jour Windows / Office pour éliminer les bogues

• Supprimer les fichiers avec :(deux points) dans les noms de fichiers des instantanés, la suggestion de txgsync sur le fil reddit créé par ewwhite => n'a pas fait de différence

  J'ai vu quelque chose de similaire à cela lorsque la fonctionnalité "versions précédentes" de Windows est activée avec des instantanés automatiques qui incluent un caractère ":". Il suffit de tirer au vent avec cela, mais cela vaut peut-être le coup d'œil, car le caractère ":" n'est pas autorisé dans les noms de fichiers Windows.

• Surveillance de l'accès aux fichiers: comme suggéré par shodanshok, j'ai utilisé DTraceet ce script pour surveiller l'accès aux fichiers. Je l'ai utilisé lors de l'enregistrement du fichier ouvert déjà lu, supprimé la sortie non liée et les informations personnelles, et le résultat s'articule autour de trois fichiers:

  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
  

  La même procédure sur un autre serveur où le problème ne se produit pas donne un résultat similaire:

  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
  

  J'ai également ajouté des horodatages ( walltimestamp) au script, mais dans les deux cas, toutes les opérations sur les fichiers ont lieu à la même seconde. => n'a pas fait de différence

• Importez des disques sur un autre hôte pour vérifier si la fragmentation du pool ou les disques sont défectueux => n'a pas fait de différence
• Déplacez les données et le pool racine sur une machine identique pour exclure le câblage, la carte mère, etc. => le problème persiste, il doit donc s'agir du pool racine (logiciel) ou d'un matériel spécifique incompatible avec le logiciel (ou soudainement devenu incompatible. ..)

Pourriez-vous suggérer autre chose qui pourrait être à l'origine de ce comportement? Ou avez-vous vécu quelque chose de similaire? parce que je n'ai rien trouvé d'utile en ligne, je soupçonne qu'il s'agit d'un étrange problème matériel (car il est limité à une seule machine) ou d'un problème avec Windows / Office.

Solution:

Le problème affecte uniquement OmniOS r151018, pas les versions précédentes. Ce fil sur la liste de diffusion omnios-discuter était exactement à propos de mon problème, citation de Geoff:

J'ai vu un fil similaire avec le forum Nexenta. Il semble y avoir un problème avec opslock. J'ai désactivé opslock et nous allons bien maintenant.

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

Je ne sais pas pourquoi cela ne mord pas plus de gens.

Donc biteCount++;je suppose. Le problème a été résolu en appliquant le correctif et en effectuant un redémarrage rapide.

Leçons pour l'avenir: avant de tenter un dépannage, utilisez simplement la recherche avancée sur les listes de diffusion officielles, car votre problème s'est probablement déjà produit sur la machine de quelqu'un d'autre. Faites également tourner une machine virtuelle rapide pour éliminer tout logiciel, mise à jour ou erreur de configuration avant de rechercher des erreurs matérielles.

Comment j'y suis arrivé:

Après plusieurs tests différents, comme indiqué dans la question mise à jour, je l'ai limitée aux problèmes logiciels ou aux conflits matériel / pilote sur le matériel spécifique. Pour exclure le second, j'ai installé deux nouvelles machines virtuelles OmniOS, r151018 et r151016 sur un autre hôte et configuré à la main un partage SMB de base sur chacune d'elles.

Le r151018 a rencontré le problème, le r151016 fonctionne bien. Je soupçonne que je ne l'ai pas remarqué lors de mes tout premiers tests, car je n'ai annulé que quelques mises à jour sur r151018, pas une version antérieure. Je pense que le problème devait exister plus longtemps que je ne le pensais.

Lorsque je cherchais un moyen de mettre à jour les packages un par un, j'ai regardé la liste de diffusion et recherché smbau cours des 6 derniers mois, où la bonne solution / le même problème est apparu, remontant à mai.