Atualiza o tempo de acesso ao arquivo no cache de leitura de discos do Linux / Discard

Question

Estou fazendo uso do tempo de acesso para analisar algum processo de construção, mas ele não está funcionando da maneira que eu quero: o tempo de acesso é atualizado na primeira vez que eu leio o arquivo, ele permanece o mesmo por um longo tempo, ou até a próxima reinicialização. Por exemplo:

$ ll -u some_file
-rw-r--r-- 1 root root 1.3M 2010-04-07 10:03 some_file
$ grep abcdef some_file
$ ll -u some_file
-rw-r--r-- 1 root root 1.3M 2010-04-07 11:24 some_file
# The access time is updated

# waiting a few minutes...
$ grep abcdef some_file
$ ll -u some_file
-rw-r--r-- 1 root root 1.3M 2010-04-07 11:24 some_file
# The access time has not been updated :(

Suponho que o arquivo seja armazenado em buffer pelo Linux na memória livre, a única vez que essa cópia é acessada nos tempos subsequentes por motivos de velocidade. Uma solução seria descartar os buffers na memória. Depois de pesquisar em alguns fóruns, encontrei:

sync
echo 1 > /proc/sys/vm/drop_caches
echo 2 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/drop_caches

Mas não está funcionando, parece que só sincroniza os buffers de gravação, não os de leitura. Pode ser que seja devido a alguma configuração de kernel customizada na minha distro (fedora 9)?

Ou estou sentindo falta de algo aqui? Existe uma maneira de conseguir essa atualização de tempo de acesso?

Note também que não quero simular algumas gravações em toda a minha árvore de arquivos. Como estou usando algum sistema de compilação baseado no makefile, isso fará com que todo o projeto seja compilado novamente.

editar:

Estou usando um sistema de arquivos ext3 padrão, sem opções especiais.

/dev/sda1 on / type ext3 (rw)

Eu tentei remontá-lo com strictatime (não reconhecido) e atime (sem diferença, acho que foi o valor padrão).

    

Answer 1

Ok, este comportamento foi devido ao kernel específico do Fedora 9 que desabilita a atualização do tempo de acesso padrão por razões de otimização (escrever o disco para cada leitura é muito demorado).

A opção DEFAULT_RELATIME (no meu caso, kernel 2.6.27.25) foi definida, o que desativa a atualização do tempo de acesso se a última atualização ocorreu menos de um dia atrás.

A opção de compilação do kernel doc dá a opção de inicialização do kernel norelatime , o que desabilita esse recurso ... mas não funcionou!

Para modificar com sucesso esse comportamento, eu realmente fiz:

echo 60 > /proc/sys/fs/relatime_interval

que diminuem esse intervalo para 1 minuto.

Obrigado pela ajuda que me levou a esta solução.

    

Answer 2

Você está usando as opções de montagem noatime ou relatime? Você pode ver se está com o comando mount :

[kbrandt@kbrandt-opadmin: ~] mount
/dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro)

Se assim for, remonte o sistema de arquivos sem essas opções (ou provavelmente melhor para este caso seria editar a opção de /etc/fstab e apenas reinicializar). Essas opções são do sistema de arquivos independentes . A descrição dessas opções está em "OPÇÕES DE MONTAGEM INDEPENDENTE DO FILESYSTEM" em man mount , mas basicamente elas impedem ou limitam o tempo de atualização para aumentar o desempenho.

Não tenho certeza se esta é a solução para o seu problema, mas como você está dependendo do tempo de acesso, eu recomendo que você faça isso de qualquer maneira.

Como um aparte, você pode querer perguntar aqui ou em stackoverflow sobre como analisar o seu processo de compilação em particular para ter certeza de que atime é o caminho certo a seguir.

Atualização:
O stat -c "%x" filename mostra a mesma coisa? (Ignore minha última atualização, não tenha percebido a opção -u ...), mas talvez haja algo acontecendo com o ll alias, por isso, verifiquei com stat para ter certeza.

Além disso, você disse / não tem noatime, mas você está fazendo esses testes no sistema raiz e não em outro sistema de arquivos, como uma montagem nfs ou algo assim?

O touch -a -t 199812130530 consegue alterar o tempo de acesso?