Situação:

O seguinte problema estranho ocorreu em um único servidor de arquivos executando o OmniOS r151018 (95eaa7e) que atende arquivos por SMB para Windows e OS X convidados.

Salvar determinados arquivos (.docx, .xlsx, algumas imagens) por meio da janela de diálogo "Salvar como..." em um compartilhamento SMB resulta em um atraso de cerca de 3 a 5 segundos, em que o aplicativo não responde. arquivo é salvo normalmente.

O problema ocorreu "durante a noite", sem fazer nada para o servidor, mas é difícil precisar a data exata, pois as reclamações dos usuários só chegaram algum tempo depois da primeira ocorrência. Após uma reinicialização do servidor, um vdev do pool raiz espelhado não estava disponível, mas uma inspeção mais detalhada não encontrou nenhuma falha no dispositivo e ele foi reanexado ao pool. O problema ainda persiste.

Algumas observações:

• Acontece em todos os clientes do Windows 7
• Isso acontece para todos os tamanhos de arquivo
• Acontece em todos os compartilhamentos desta máquina, independentemente das permissões
• Isso acontece para armazenamento mais rápido importado no host por iSCSI de outro servidor
• A velocidade normal de cópia é de 110 MB/s em GBit Ethernet
• Os dados e o pool raiz parecem estar bem
• Isso não acontece em outros servidores de arquivos
• Isso não acontece quando o arquivo é salvo localmente e depois copiado pelo explorer
• Não acontece no OS X (só poderia testar com o OpenOffice)
• dmesgmostra várias contagens NOTICE: bge0: interrupt: flags 0x0 - not updated?com vários valores, mas também era o caso antes e não prejudicou

Outras ideias/planos:

Como não há uma mensagem de erro clara a ser encontrada, talvez seja necessário fazer algumas tentativas e erros para procurar a causa. Algumas coisas que considerarei ( os resultados estão em itálico ):

• Substitua a placa de rede Broadcom por uma placa Intel => não fez diferença
• Substitua o pool raiz por SSDs SATA (atualmente pendrives de memória SLC que funcionaram bem por mais de 3 anos) => não fez diferença
• Verifique a rede intermediária (hardware, por conexão direta ao servidor)
• Captura de tráfego com WireShark: difícil se você não sabe exatamente o que está procurando
• Reverta para um ambiente/versão de inicialização anterior do OmniOS para descartar conflitos de software => não fez diferença
• Reverta as atualizações do Windows/Office para descartar bugs

• Remover arquivos com :(dois pontos) em nomes de arquivos de instantâneos, sugestão de txgsync no tópico do reddit criado por ewwhite => não fez diferença

  Eu vi algo semelhante a isso quando o recurso "versões anteriores" do Windows é ativado com instantâneos automáticos que incluem um caractere ":". Apenas tiro ao vento com isso, mas pode valer a pena dar uma olhada, pois o caractere ":" não é permitido nos nomes de arquivo do Windows.

• Monitoramento de acesso a arquivos: conforme sugerido por shodanshok, usei DTracee este script para monitorar o acesso a arquivos. Usei-o enquanto salvava o arquivo já aberto, removi saídas não relacionadas e informações pessoais, e o resultado gira em torno de três arquivos:

  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
  

  O mesmo procedimento em outro servidor onde o problema não ocorre produz um resultado semelhante:

  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
  

  Também adicionei timestamps ( walltimestamp) ao script, mas em ambos os casos todas as operações de arquivo ocorrem no mesmo segundo. => não fez diferença

• Importar discos em outro host para verificar se a fragmentação do pool ou os discos estão com defeito => não fez diferença
• Mova os dados e o pool raiz para uma máquina idêntica para descartar cabeamento, placa principal etc. => o problema persiste, então deve ser o pool raiz (software) ou um hardware específico que é incompatível com o software (ou se tornou incompatível repentinamente. ..)

Você poderia sugerir mais alguma coisa que seja a causa desse comportamento? Ou você experimentou algo semelhante? como não consegui encontrar nada útil online, suspeito que seja um problema estranho de hardware (porque está limitado a uma máquina) ou um problema com o Windows/Office.