ls -l, mas não ls --color = nunca lento no diretório nfs-mounted, se simulatenously gravar nesse diretório

Question

quando eu despejo dados em um diretório montado pelo NFS, a leitura de modos de arquivos (por exemplo, ls -l ) é várias ordens de magnitude mais lenta do que uma listagem simples de arquivos (por exemplo, ls --color=never ). Eu gostaria de entender o porquê.

Se nada estiver sendo gravado nesse diretório ls -l retornará quase imediatamente. No entanto, se eu, então, criar alguma IO com, por exemplo, dd if=/dev/zero of=dd.img count=100M && rm dd.img , ls -l será interrompido por até meio minuto, mas ls --color=never ou getdents retornam quase imediatamente. Em outras palavras, assim que os modos de arquivo forem lidos, ls parará, mas somente se eu gravar no mesmo diretório ao mesmo tempo. Eu vejo esse comportamento em vários diretórios montados com diferentes opções de NFS.

O cliente está executando o cliente CentOS 6.1 (versão do kernel 2.6.32-358.2.1.el6.x86_64). Não sei o que o servidor está executando (algum sistema proprietário de alto desempenho) e não tenho direitos de administrador. Minha pergunta é simplesmente se esse tipo de comportamento é esperado em determinados cenários e, em caso afirmativo, quais?

Muito obrigado,

Andreas

    

Answer 1

getdents e ls --color=never requerem apenas a leitura do diretório. ls -l e ls --color=auto requerem a leitura do diretório e os inodes correspondentes a todas as entradas de diretório . ( ls -l , porque precisa obter o modo, contagem de links, proprietário, tamanho e data de modificação, porque exibe esses campos e ls --color=auto , porque precisa obter o modo (e talvez contagem de links e tamanho), porque determina a cor em parte do tipo de arquivo (arquivo simples, diretório, fifo, symlink, etc.), capacidade de escrita, executabilidade, setuid, setgid e o bit sticky (e talvez o tamanho e o tamanho do link).)

Obter muitas informações de um servidor remoto pode levar muito tempo especialmente se estiver distante ou intrinsecamente lento (para incluir estar muito carregado). É comum que os clientes armazenem em cache os resultados, então, quando o usuário pede informações que já foram recuperadas, o cliente pode exibir os resultados em cache (salvos) em vez de buscá-los novamente.

If nothing’s being written to the directory, ls -l will return almost immediately.

Eu suspeito que o cliente NFS (parte do seu sistema CentOS) pergunta ao servidor NFS, "What's up?", e o servidor responde: "Estou entediado. Nada aconteceu aqui por um tempo. Assim, o cliente sabe que é seguro mostrar as informações em cache.

However, if I then create (… a file …), ls -l will hang for up to half a minute, …

O cliente pergunta "O que está acontecendo?" e o servidor responde: "As coisas mudaram para cá". Então o cliente sabe que seu cache é inválido, e por isso precisa reler o diretório e todos os inodes (através do servidor). Isso também seria verdade para ls --color=auto .

… but ls --color=never or getdents return almost immediately. 

Como esses comandos não exigem as informações do inode, a única coisa que precisa ser relida é o próprio diretório, que leva muito menos tempo.