compreendendo lsof durante longa operação em arquivo grande

Question

Antecedentes

Eu estou executando o Musicbrainz Picard para atualizar um arquivo ogg de ~ 11M em um disco de 500GB NTFS (Transcend StoreJet) conectado via USB e montado usando autofs. A conexão é através da estação de encaixe. Não posso ter certeza de que sempre desmontei corretamente ...

Estou preocupado porque a operação está demorando muito; Eu esperava que toda a pasta fosse processada em minutos, mas talvez ainda demore algumas horas. Quando eu disparo iotop (1) , ele informa ~ 25K / s de gravação em disco, com ~ 99% para o processo picard. (Picard não está totalmente travado, a GUI atualiza / responde uma vez em alguns minutos).

Na esperança de ver algum progresso, eu continuo checando o lsof; toda a saída se parece com:

$ lsof /mnt/greeno-ntfs
COMMAND  PID    USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
picard  2885 amahdal  mem    REG   8,17 11121609 44661 /mnt/greeno-ntfs/path/to.ogg
picard  2885 amahdal   14u   REG   8,17 11121609 44661 /mnt/greeno-ntfs/path/to.ogg
picard  2885 amahdal   16u   REG   8,17 11121609 44661 /mnt/greeno-ntfs/path/to.ogg

mas não consigo realmente entender todas as observações - só posso fazer algumas suposições. Então pensei em perguntar aqui.

Perguntas

• É normal que haja 3 FDs para o arquivo? Um 'mem' e dois "regulares"?

  Eu tentei criar um script trivial que abre e atualiza um arquivo (dormindo no meio para levar muito tempo), e não, havia apenas um FD regular ( 5u ), aparentemente aparentemente normal, não se comportará como isso.

  Suposição: É um resultado da técnica (talvez genérica) de lidar com E / S de arquivos potencialmente longos que o Picard (ou seu lib) deliberadamente explica. Se assim for, alguém pode lançar alguma luz sobre isso? (Por exemplo, por que 2 + 1?)

• Como eu notei, a coluna SIZE / OFFSET está diminuindo ao longo do tempo.

  Suposição: Isso corresponde a Picard, na verdade, procurando dentro do arquivo e atualizar, certo?

Suposições aleatórias - neste ponto, algum deles faz sentido como causa possível?

• Picard é buggy (extremamente ineficiente na atualização / redução),

• o disco está falhando (ele tem cinco anos ou mais ...),

• o sistema de arquivos está mal montado (quem sabe montar ntfs otimamente),

• o sistema de arquivos está quebrado no un / docking (não é possível verificar como eu não tem chkdsk) ...

Então, o que vem depois? O que posso ver em seguida para saber o que está acontecendo?

    

Answer 1

Seus palpites são fáceis de testar, com exceção do Picard sendo buggy. Se o arquivo tiver apenas 11 MB, basta copiá-lo para / dev / shm (RAM) ou um sistema de arquivos nativo para testá-lo.

E eu certamente esperaria que o NTFS fosse muito mais lento e usasse muito mais CPU, mas não mudaria minutos para horas normalmente. Evitar o NTFS deve ser a primeira coisa a testar.

E a saída lsof pode ser muito estranha ... às vezes até "lsof -p $ pid" vs "lsof / path" tem saída diferente, mesmo se a segunda listar apenas um pid. Então eu não tentaria descobrir se isso é "normal" ou não.

Se você quiser saber sobre a busca e a gravação do arquivo, use strace, não lsof.