Por que 'encontrar' gosta tanto de 'stat' ou 'fstat'?

Question

Estou tentando fazer com que /usr/bin/find mostre algo significativo sem fazer nenhum tipo de stat , sem resultados úteis até o momento. Se eu forçar a inibição de stat , o find parará nos subdiretórios.

Como a página de manual de getdents syscall diz, há d_type campo, então find já deve ter algumas informações necessárias para decisões.

Por que precisamos de stat , independentemente de -L , -H ou de quaisquer opções.

    

Answer 1

Use a fonte, Luke!

Na fonte find do GNU (estou vendo a versão 4.2.2), o código que percorre as árvores de diretórios está em gnulib/lib/fts.c . Na linha 1123, há o seguinte comentário:

Record what fts_read will have to do with this entry. In many cases, it will simply fts_stat it, but we can take advantage of any d_type information to optimize away the unnecessary stat calls. I.e., if FTS_NOSTAT is in effect and we're not following symlinks (FTS_PHYSICAL) and d_type indicates this is not a directory, then we won't have to stat it at all. If it is a directory, then (currently) we stat it regardless, in order to get device and inode numbers. Some day we might optimize that away, too, for directories where d_ino is known to be valid.

Então, eles pensaram na otimização que você descreve, mas ela não está implementada.

    

Answer 2

A página de manual citada para getdents é específica do Linux e não se aplica para todos os tipos de sistema de arquivos (por exemplo, a página de manual não menciona procfs ou nfs ), enquanto o GNU encontrar não é específico da plataforma (sua página de manual menciona o SELinux, que é sem dúvida um recurso útil a ser levado em conta). Ele poderia ser otimizado para este caso especial também.

Mesmo que o recurso esteja disponível, a página de manual recomenda:

All applications must properly handle a return of DT_UNKNOWN.

Ou seja, as informações, se disponíveis, podem ser úteis, mas não é garantido que estejam presentes.

Com todos esses inconvenientes, os desenvolvedores de find talvez não percebam a necessidade dessa otimização. Um usuário motivado pode se aprofundar no código-fonte para ver como fazer isso e propor uma alteração ifdef adequada.

@Nate Eldredge observa que alguém começou nessa direção. O manual find indica 7.2 d_type Optimization

When this feature is enabled, find takes advantage of the fact that on some systems readdir will return the type of a file in struct dirent.

O recurso foi mencionado pela primeira vez em

2005-01-17  James Youngman  <[email protected]>
    * configure.in, find/defs.h, find/find.c, find/parser.c, find/pred.c, find/tree.c, find/util.c:
    Implemented d_type optimisation but not working correctly, so currently disabled

Mais tarde, foi revisado para usar o gnulib para suportar isso:

2010-04-08  James Youngman  <[email protected]>

    Adopt the use of the gnulib module d-type.
    * import-gnulib.config (modules): Import the d-type module.
    * configure.ac: Remove old struct dirent.d_type detection logic
    (since we now use the gnulib macro from the d-type module for
    this).

A versão 4.2.2 é bastante antiga (talvez um erro de digitação), a propósito: 4.2.3 data de 2004, e é anterior a estas entradas do changelog. A tag de lançamento atual no git é 4.5.14 (mid -2014).

Independentemente do status de uma otimização d_type , os desenvolvedores estão interessados em reduzir o número de chamadas para stat . Uma nota de 4.5.4 (2009-03-10) diz por exemplo:

The ftsfind executable also now avoids calling stat() functions to discover the inode number of a file, if we already read this information from the directory. This does provide a speed-up, but only for a restricted set of commands such as "find . -inum 4001". This fix is listed below as bug #24342.

Em resumo: OP perguntou

Why need to for stat regardless of -L, -H or whatever options.

O motivo é que é um caso especial que é problemático fazer com que ele funcione perfeitamente em vez de stat em todos os cenários em que find pode precisar disso e que leva tempo para isso.