Situazione:

Il seguente strano problema si è verificato su un singolo file server che esegue OmniOS r151018 (95eaa7e) che serve file su SMB su guest Windows e OS X.

Il salvataggio di determinati file (.docx, .xlsx, alcune immagini) tramite la finestra di dialogo "Salva con nome ..." su una condivisione SMB comporta un ritardo di circa 3-5 secondi, in cui l'applicazione non risponde affatto, successivamente il il file viene salvato normalmente.

Il problema si è verificato "durante la notte", senza fare nulla al server, ma è difficile individuare la data esatta, poiché i reclami degli utenti sono arrivati ​​solo dopo il primo verificarsi. Dopo un riavvio del server, un vdev del pool root con mirroring non era disponibile, ma un'ispezione più ravvicinata non ha rilevato errori sul dispositivo ed è stato ricollegato al pool. Il problema persiste ancora.

Alcune osservazioni:

• Succede su tutti i client Windows 7
• Succede per tutte le dimensioni di file
• Succede su tutte le condivisioni di questa macchina, indipendentemente dalle autorizzazioni
• Succede per una memorizzazione più veloce importata sull'host tramite iSCSI da un altro server
• La normale velocità di copia è di 110 MB / sec su GBit Ethernet
• Il pool di dati e root sembra andare bene
• Non succede su altri file server
• Non succede quando il file viene salvato localmente, quindi copiato tramite Explorer
• Non succede su OS X (potrebbe solo testarlo con OpenOffice)
• dmesgmostra diversi conteggi NOTICE: bge0: interrupt: flags 0x0 - not updated?con vari valori, ma questo era anche il caso prima e non ha fatto alcun male

Ulteriori idee / piani:

Poiché non è possibile trovare un messaggio di errore chiaro, potrebbe essere necessario eseguire alcune prove ed errori nella ricerca della causa. Alcune cose che prenderò in considerazione (i risultati sono in corsivo ):

• Sostituire la scheda di rete Broadcom con una scheda Intel => non ha fatto differenza
• Sostituisci il pool di root con SSD SATA (attualmente chiavette USB con memoria SLC che hanno funzionato bene per oltre 3 anni) => non ha fatto differenza
• Controlla la rete tra (hardware, tramite connessione diretta al server)
• Cattura del traffico con WireShark: difficile se non sai esattamente cosa stai cercando
• Ripristinare un precedente ambiente / versione di avvio OmniOS per escludere conflitti software => non ha fatto differenza
• Ripristina gli aggiornamenti di Windows / Office per escludere i bug

• Rimuovi i file con :(due punti) nei nomi dei file dalle istantanee, il suggerimento di txgsync sul thread reddit creato da ewwhite => non ha fatto differenza

  Ho visto qualcosa di simile a questo quando la funzione "versioni precedenti" di Windows è abilitata con istantanee automatiche che includono un carattere ":". Basta sparare al vento con questo, ma potrebbe valere la pena dare un'occhiata in quanto il carattere ":" non è consentito nei nomi di file di Windows.

• Monitoraggio di accesso ai file: come suggerito da shodanshok, ho usato DTracee questo script per monitorare l'accesso ai file. L'ho usato durante il salvataggio del file aperto alread, rimosso l'output non correlato e le informazioni personali e il risultato è incentrato su tre file:

  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 stessa procedura su un altro server in cui non si verifica il problema produce un risultato simile:

  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
  

  Ho anche aggiunto timestamp ( walltimestamp) allo script, ma in entrambi i casi tutte le operazioni sui file avvengono nello stesso secondo. => non ha fatto differenza

• Importa dischi su un altro host per verificare se la frammentazione del pool o i dischi sono difettosi => non ha fatto la differenza
• Spostare i dati e il pool di root su una macchina identica per escludere il cablaggio, la scheda madre, ecc. => Il problema persiste, quindi deve essere il pool di root (software) o un hardware specifico incompatibile con il software (o improvvisamente diventato incompatibile. ..)

Potresti suggerire qualcos'altro che potrebbe essere la causa di questo comportamento? O hai provato qualcosa di simile? poiché non sono riuscito a trovare nulla di utile online, sospetto che si tratti di uno strano problema hardware (perché è limitato a un solo computer) o di un problema con Windows / Office.

Soluzione:

Il problema riguarda solo OmniOS r151018, non le versioni precedenti. Questo thread sulla mailing list di omnios-discuss riguardava esattamente il mio problema, citazione da Geoff:

Ho visto un thread simile con il forum Nexenta. Sembra esserci un problema con opslock. Ho disabilitato opslock e ora stiamo bene.

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

Non sono sicuro del perché questo non morda più persone.

Quindi biteCount++;immagino. Il problema è stato risolto applicando la correzione e facendo un riavvio rapido.

Lezioni per il futuro: prima di tentare qualsiasi risoluzione dei problemi, basta utilizzare la ricerca avanzata nelle mailing list ufficiali, perché molto probabilmente il tuo problema si è già verificato sulla macchina di qualcun altro. Inoltre, avvia una VM veloce per escludere eventuali errori di software, aggiornamenti o configurazione prima di cercare errori hardware.

Come ci sono arrivato:

Dopo diversi test, come visto nella domanda aggiornata, l'ho ridotto a problemi software o conflitti hardware / driver sull'hardware specifico. Per escludere il secondo, ho installato due nuove macchine virtuali OmniOS, r151018 e r151016 su un altro host e ho configurato manualmente una condivisione SMB di base su ciascuna di esse.

R151018 ha riscontrato il problema, r151016 funziona correttamente. Sospetto di non averlo notato nei miei primi test, perché ho eseguito solo il rollback di alcuni aggiornamenti su r151018, non su una versione precedente. Penso che il problema debba essere esistito più a lungo di quanto pensassi.

Quando cercavo un modo per aggiornare i pacchetti solo uno per uno, ho guardato la mailing list e ho cercato smbnegli ultimi 6 mesi, in cui è emersa la soluzione corretta / lo stesso problema, risalente a maggio.