Enumerar \ escrevendo arquivos em um diretório específico trava o comando

Question

Estou me comunicando com uma máquina remotamente através de ssh . Esta máquina executa um Linux customizado e possui um conjunto muito limitado de comandos.

Em algum momento, um diretório específico recusa arquivos a serem gravados nele. Executar ls , pressionar "tab" para preencher automaticamente um nome de arquivo ou excluir arquivos usando um curinga, trava o comando.

Depois de abrir uma nova sessão ssh , acessar ps | grep D mostra o seguinte:

  PID  Uid        VSZ Stat Command
  628 root            DWN [jffs2_gcd_mtd4]
  930 root       2912 D   rm /mnt/flash/system/config
  995 root       2400 D   scp -t /mnt/flash/system/
 2083 root       3044 D   ls -AlSh /mnt/flash/system
 6994 root       2912 D   chmod +x /mnt/flash/system/config
13281 root       3052 S   grep D
22220 root       2400 D   scp -t /mnt/flash/system/

A execução do comando mount mostra o seguinte:

rootfs on / type rootfs (rw)
/dev/root on / type ext2 (rw)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw)
tmpfs on /tmp type tmpfs (rw)
/dev/mtdblock4 on /mnt/flash type jffs2 (rw)

Observe que os processos com o estado D (indicam que o processo está executando uma operação de E / S de disco. Normalmente, esse estado não deve ser observado, mas executar ps várias vezes mostra o mesmo estado. o processo está preso em uma operação de E / S) está excluindo, listando, editando ou gravando arquivos no caminho montado /mnt/flash .

Este sistema de arquivos do caminho montado é jffs2 (observe que um dos processos mostrados é jffs2_gcd_mtd4 com o estado de DWN ).

Tenha em mente que não tenho uma ideia sólida sobre o Linux, então, por favor, seja o mais simples possível.

• Então, qual é o estado DWN ? Está indicando que os processos foram descontados (isto é, para baixo)?
• Como posso resolver este problema? Não consigo editar arquivos neste caminho e reiniciar a máquina é uma opção cara (por exemplo, logística).

Answer 1

O status do ps DWN é a combinação dos sinalizadores:

D    uninterruptible sleep (usually IO)
W    paging (not valid since the 2.6.xx kernel)
N    low-priority (nice to other users)

Estar preso em Disk-wait é o que é bastante indicativo de um bug de driver. Um driver conectado a uma unidade terrivelmente quebrada deve eventualmente expirar e retornar o EIO para as chamadas do sistema que o acessam.

Se você estiver executando um kernel "customizado" como você diz com um sistema de arquivos tão raro que eu não teria ouvido falar dele antes de sua pergunta onde um driver pode ficar preso em uma espera sem fim sugere que você considere sua máquina de produção quebrado.

Pessoalmente, eu ficaria desconfiado de um driver que parece ter ficado órfão há uma década especialmente desde que as razões motivadoras para criar o driver foram obviadas principalmente pelos avanços do controlador de flash.

adicionado em resposta ao comentário :

Infelizmente, um driver encravado frequentemente irá aproveitar o canal de hardware e nada menos que uma reinicialização pode fazer com que ele seja liberado. Você diz que esse dispositivo é operacionalmente difícil de alcançar; Espero que não esteja em Marte. Antes de enviar alguém para reiniciá-lo, certifique-se de remover a montagem do dispositivo (geralmente em / etc / fstab, mas pode estar em - por exemplo - /etc/rc.local) ou então o sistema provavelmente irá travar novamente.

Como @goldilocks observou nos comentários, o hardware com falha é uma possibilidade distinta, portanto, se o flash for removível, eu enviaria o técnico com o hardware de substituição. Vale a pena notar que a memória flash tem um número limitado de ciclos de gravação antes da falha e flash mais antigo tinha um número menor de ciclos de gravação do que o flash moderno.

Quando o problema for resolvido, você poderá criar um novo sistema de arquivos na memória e montá-lo, desde que sua interface remota permita isso.