OmniOS / ZFS / Windows 7: “Salvar como” de dentro de aplicativos fica 5 segundos para todos os tamanhos de arquivo em CIFS / SMB

Question

Situação:

O seguinte problema estranho ocorreu em um único servidor de arquivos executando OmniOS r151018 (95eaa7e) servindo arquivos sobre SMB para Windows e OS X guests.

Salvar determinados arquivos (.docx, .xlsx, algumas imagens) pela 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 de forma alguma , depois o arquivo é salvo normalmente.

O problema ocorreu "durante a noite", sem fazer nada ao servidor, mas é difícil identificar a data exata, pois as reclamações dos usuários só acontecem em algum momento 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 próxima não encontrou falhas no dispositivo e foi reconectada ao pool. O problema ainda persiste.

Algumas observações:

• Isso acontece em todos os clientes do Windows 7
• Isso acontece para todos os tamanhos de arquivo
• Acontece em todos os compartilhamentos dessa máquina, independentemente das permissões
• Acontece para um armazenamento mais rápido importado no host sobre o iSCSI de outro servidor
• A velocidade de cópia normal é de 110 MB / s em relação ao GBit Ethernet
• 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 depois copiado pelo explorador
• Isso não acontece no OS X (só poderia testá-lo com o OpenOffice)
• dmesg mostra várias contagens de NOTICE: bge0: interrupt: flags 0x0 - not updated? com vários valores, mas isso também foi o caso antes e não causou dano

Mais ideads / planos:

Como não há uma mensagem de erro clara a ser encontrada, talvez seja necessário fazer uma pesquisa de tentativa e erro para a causa. Algumas coisas que vou considerar ( resultados estão em itálico ):

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

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

  I've seen something similar to this when the Windows "previous versions" feature is enabled with automatic snapshots that include a ":" character. Just shooting at the wind with this, but may be worth a look as the ":" character is not allowed in Windows file names.

• Monitoramento do acesso a arquivos: como sugerido por shodanshok, usei DTrace e script para monitorar o acesso a arquivos. Usei-o enquanto salvava o arquivo aberto alread, removia a saída não relacionada e as informações pessoais, e o resultado se concentra 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 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

• Importe 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 o cabeamento, a placa-mãe etc. = > problema persiste, então deve ser o conjunto raiz (software) ou um hardware específico que é incompatível com o software (ou de repente se tornou incompatível ...)

Você poderia sugerir qualquer outra coisa que seja a causa desse comportamento? Ou você experimentou algo semelhante? porque não encontrei nada de útil on-line, suspeito que seja um problema de hardware estranho (porque é limitado a uma máquina) ou um problema com o Windows / Office.

    

Answer 1

Solução:

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

I saw a similar thread with Nexenta forum. There seems to be an issue with opslock. I disabled opslock and we are good now.

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

Not sure why this isn't biting more people.

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 e-mails oficiais, pois é bem provável que seu problema já tenha ocorrido na máquina de outra pessoa. Além disso, crie uma VM rápida para descartar softwares, atualizações ou erros de configuração antes de procurar por erros de hardware.

Como cheguei lá:

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

O r151018 experimentou o problema, o r151016 funciona bem. Eu suspeito que eu não notei isso nos meus primeiros testes, porque eu só revi algumas atualizações no r151018, não de volta para 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 e-mails e procurei smb dos últimos 6 meses, onde a solução correta / o mesmo problema apareceu, com data de maio.