Situação:

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

Salvar certos arquivos (.docx, .xlsx, algumas imagens) na janela "Salvar como ..." em um compartilhamento SMB resulta em um atraso de cerca de 3 a 5 segundos, em que o aplicativo não responde, depois a mensagem arquivo é salvo normalmente.

O problema ocorreu "durante a noite", sem fazer nada para o servidor, mas é difícil identificar a data exata, pois as reclamações dos usuários só ocorreram algum tempo após a 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 foi anexado novamente ao pool. O problema ainda persiste.

Algumas observações:

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

Ideads / planos adicionais:

Como não há nenhuma mensagem de erro clara, talvez seja necessário executar algumas tentativas e erros ao procurar a causa. Algumas coisas que vou considerar (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, os pendrives USB de memória SLC que funcionaram bem por mais de 3 anos) => não fizeram diferença
• Verifique a rede no meio (hardware, por conexão direta ao servidor)
• Captura de tráfego com o WireShark: difícil se você não sabe exatamente o que está procurando
• Reverta para uma versão / ambiente 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 erros

• Remova arquivos com :(dois pontos) nos nomes de arquivos das capturas instantâneas, sugestão por txgsync no thread do reddit criado por ewwhite => não fez diferença

  Vi algo parecido com isso quando o recurso "versões anteriores" do Windows é ativado com instantâneos automáticos que incluem um caractere ":". Basta atirar no vento com isso, mas pode valer uma olhada, pois o caractere ":" não é permitido nos nomes de arquivos do Windows.

• Monitoramento de acesso a arquivos: como sugerido por shodanshok, eu usei DTracee este script para monitorar o acesso de arquivo. Usei-o ao salvar o arquivo aberto anterior, removi a saída não relacionada e as informações pessoais, e o resultado é centralizado em 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 em que o problema não ocorre gera 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

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

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

Solução:

O problema afeta apenas o OmniOS r151018, não as versões anteriores. Esta discussão na lista de discussão omnios-discuss foi exatamente sobre o meu problema, citação de Geoff:

Eu vi um tópico semelhante no fórum Nexenta. Parece haver um problema com o opslock. Desativei o opslock e estamos bem agora.

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

Não sei por que isso não está mordendo mais pessoas.

Então biteCount++;eu acho. O problema foi resolvido aplicando a correção e fazendo uma reinicialização rápida.

Lições para o futuro: antes de tentar qualquer solução de problemas, basta usar a pesquisa avançada nas listas de discussão oficiais, porque provavelmente o seu problema já ocorreu na máquina de outra pessoa. Além disso, gire uma VM rápida para descartar qualquer software, atualizações ou erros de configuração antes de procurar erros de hardware.

Como cheguei lá:

Após vários testes diferentes, como visto na pergunta atualizada, reduzi-o a problemas de software ou conflitos de hardware / driver no hardware específico. Para descartar o segundo, instalei duas máquinas virtuais OmniOS novas, r151018 e r151016 em outro host e configurei manualmente um compartilhamento SMB básico em cada uma delas.

O r151018 enfrentou o problema, o r151016 funciona bem. Eu suspeito que não notei isso nos meus primeiros testes, porque revirei apenas algumas atualizações na r151018, e não em uma versão anterior. Eu acho que o problema deve ter existido por mais tempo do que eu supus.

Ao procurar uma maneira de atualizar os pacotes apenas um por um, examinei a lista de correspondência e procurei smbnos últimos 6 meses, onde a solução / mesmo problema correto apareceu, datado de maio.