Comportamento estranho no comando mv - talvez problema de chamada sys aberta?

2

Estou observando um comportamento muito estranho do comando "mv" que pode (ou não) estar relacionado à chamada de sistema "aberta". Estamos rodando o RedHat v5. Existem dois dispositivos de armazenamento separados, um montado em "/ diskTo" e o outro "/ diskFrom" (para este exemplo).

Em operações normais, estamos movendo (mv'ing) centenas, se não milhares, de arquivos de / diskFrom para / diskTo. A maioria dos arquivos se move bem. No entanto, de, digamos, 1000 arquivos, temos 1-5 que falham. A falha é um erro de permissão negada. Quando verificamos o destino do arquivo, existe um arquivo existente , mas o conteúdo do inode é lixo. Por exemplo, o registro de data e hora é lixo ("1969", mas varia) e as permissões são "0".

Então, imaginei que deveríamos executar strace nos comandos mv e capturar a saída das falhas. Aqui está o que eu encontrei:

munmap(0x2b0328770000, 4096)            = 0
geteuid()                               = 31169
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff90de9500) = -1 ENOTTY (Inappropriate ioctl for device)
stat("/diskTo/foo.dat", 0x7fff90de95d0) = -1 ENOENT (No such file or directory)
lstat("/diskFrom/bar.dat", {st_mode=S_IFREG|0444, st_size=234632119, ...}) = 0
lstat("/diskTo/foo.dat", 0x7fff90de9370) = -1 ENOENT (No such file or directory)
rename("/diskFrom/bar.dat", "/diskTo/foo.dat") = -1 EXDEV (Invalid cross-device link)
unlink("/diskTo/foo.dat") = -1 ENOENT (No such file or directory)
open("/diskFrom/bar.dat", O_RDONLY|O_NOFOLLOW) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=234632119, ...}) = 0
open("/diskTo/foo.dat", O_WRONLY|O_CREAT|O_EXCL, 0400) = -1 EEXIST (File exists)
write(2, "mv: ", 4)                     = 4
write(2, "cannot create regular file '/diskTo"..., 76) = 76
write(2, ": File exists", 13)           = 13
write(2, "\n", 1)                       = 1

Como você pode ver, o unlink é chamado, o que retorna -1, o que mostra que o arquivo não existe. Então, "mv" tenta abrir o arquivo e recebe um erro EEXIST. Mas o arquivo não pode existir! Eu não estou mostrando isso aqui, mas o script que está criando este caso de teste está usando números exclusivos para criar diretórios - então é muito improvável (se não impossível) que o arquivo realmente existisse. Sem mencionar que o unlink comprova que o arquivo não existia.

Este poderia ser um problema de como o open está criando o conteúdo do inode? Não tenho certeza de onde procurar neste momento. Talvez olhando para "mv" mais, ou a chamada "aberta" do sistema?

    
por Jmoney38 09.04.2013 / 14:11

1 resposta

1

Executar um fsck(8) completo no disco, parece que alguns inodes bagunçados estão flutuando (ou são criados na hora). Execute badblocks(8) para ver se há algo errado com o disco. Veja se os logs (ou outros diagnósticos de disco) dizem algo sobre isso.

Todo o software está atualizado?

Quais sistemas de arquivos são esses? Alguma outra atividade em diskTo que possa estar interferindo? O disco está quase cheio (no espaço, em inodes) por acaso? Algum outro relatório nos logs?

Além disso, faça uma verificação completa na máquina, erros de memória podem causar algo como isso, assim como o superaquecimento. Esta é uma causa muito improvável, mas não vai doer desmontá-la e verificar os fãs e, portanto, estão funcionando corretamente, e não há terra suficiente para uma fazenda de tamanho médio dentro dela. Se a máquina não estiver conectada a um no-break ou similar, as flutuações de voltagem também poderão causar erros aleatórios.

    
por 09.04.2013 / 14:27