Início / unix / Perguntas / 570873
Accepted
Some Name
Asked: 2020-03-04 02:23:40 +0800 CST

O fstat requer acesso ao disco no Linux/ext4?

  • 772

Linux Kernel 5.3

Considere o fstatsyscall definido como int fstat(int fd, struct stat *statbuf);. O acesso ao disco é necessário para o fstatsyscall no ext4?

Eu fiz algumas pesquisas relacionadas a ele e descobri algumas informações. O ponto de entrada no kernel para a chamada do sistema é a função vfs_statx_fd. Veja como fica sua implementação:

int vfs_statx_fd(unsigned int fd, struct kstat *stat,
         u32 request_mask, unsigned int query_flags)
{
    struct fd f;
    int error = -EBADF;

    if (query_flags & ~KSTAT_QUERY_FLAGS)
        return -EINVAL;

    f = fdget_raw(fd);
    if (f.file) {
        error = vfs_getattr(&f.file->f_path, stat,
                    request_mask, query_flags);
        fdput(f);
    }
    return error;
}

Então, o que temos aqui é que o unsigned int fddescritor de arquivo real que um usuário passou para a chamada do sistema é usado para encontrar um ponteiro para o arquivo struct file. A parte crucial de sua definição é

struct file {
    //...
    struct path     f_path;
    struct inode        *f_inode;   /* cached value */
    //...
}

Então, basicamente, temos que struct filerepresenta um arquivo aberto e o struct contém referências dentryeinode

É verdade que, caso tenhamos um descritor de arquivo aberto, podemos obter todas as estatísticas apenas da memória, evitando o dispendioso acesso ao disco?

Atualização : Tentei liberar os caches do Kernel free && sync && echo 3 > /proc/sys/vm/drop_caches && freeantes de invocar o syscalle isso não afetou o tempo do stat syscall. Então, eu tendo a pensar que nenhum acesso ao disco é necessário.

linux files

1 respostas

  1. Best Answer

    Em um sistema de arquivos Ext4, o gráfico de função a partir de vfs_statx_fdé

     0)               |  vfs_statx_fd() {
 0)               |    __fdget_raw() {
 0)   0.225 us    |      __fget_light();
 0)   0.775 us    |    }
 0)               |    vfs_getattr() {
 0)               |      security_inode_getattr() {
 0)               |        selinux_inode_getattr() {
 0)               |          __inode_security_revalidate() {
 0)               |            _cond_resched() {
 0)   0.216 us    |              rcu_all_qs();
 0)   0.575 us    |            }
 0)   0.945 us    |          }
 0)               |          inode_has_perm() {
 0)   0.356 us    |            avc_has_perm();
 0)   0.709 us    |          }
 0)   2.223 us    |        }
 0)   2.808 us    |      }
 0)               |      vfs_getattr_nosec() {
 0)               |        ext4_file_getattr() {
 0)               |          ext4_getattr() {
 0)   0.203 us    |            generic_fillattr();
 0)   0.600 us    |          }
 0)   1.040 us    |        }
 0)   1.502 us    |      }
 0)   4.854 us    |    }
 0)   6.913 us    |  }

    Observar as implementações de todas essas funções mostra que não há provisão para E/S de disco. Como você supõe, os dados vêm do inode em cache.

    Veja também a página de fstat(2)manual que menciona que:

    Nota : por questões de desempenho e simplicidade, diferentes campos na statestrutura podem conter informações de estado de diferentes momentos durante a execução da chamada do sistema. Por exemplo, se st_modeou st_uidfor alterado por outro processo chamando chmod(2)ou chown(2), stat()poderá retornar o antigo st_modejunto com o novo st_uidou o antigo st_uidjunto com o novo st_mode.

    (embora isso tenha mais a ver com bloqueio do que com cache).

    Com alguns outros sistemas de arquivos, AT_STATX_FORCE_SYNCpodem ser incluídos nos sinalizadores de consulta para forçar uma sincronização remota; isso é suportado em pastas compartilhadas de convidados Ceph, FUSE, NFS e VirtualBox.

    • 8

relate perguntas