O 'bindfs --mirror = user1: user2:…' está quebrado devido ao cache de metadados do FUSE?

0

link

-m, --mirror=user1:user2:..., -o mirror=...

Takes a comma- or colon-separated list of users who will see themselves as the owners of all files. Users who are not listed here will still be able to access the mount if the permissions otherwise allow them to.

You can also give a group name prefixed with an ’@’ to mirror all members of a group. This will not change which group the files are shown to have.

Suspeito de como isso funciona com o cache do kernel do Linux de metadados de arquivos (cache de inode do VFS) ...

É possível ver o proprietário "errado" se você tiver azar? Ou bindfs corretamente usa algum recurso da implementação FUSE do kernel Linux, para forçar o cache de inode do VFS a refazer os detalhes de propriedade do inode em cada acesso do espaço de usuário?

The FUSE kernel refreshes inode attributes from the userspace FUSE process once every 3 seconds by default. This can be tuned through the fuse.attr.timeout parameter in the fuse.conf file. The fuse.attr.timeout parameter specifies the interval of time at which to refresh the inode attributes in kernel and can be used to minimize the amount of time it takes to refresh the cache.

link

attr_timeout=T

The timeout in seconds for which file/directory attributes are cached. The default is 1.0 second.

link

    
por sourcejedi 22.07.2018 / 18:49

1 resposta

0

bindfs lida com esse problema.

link

/* We need to disable the attribute cache whenever two users
   can see different attributes. For now, only mirroring can do that. */
if (is_mirroring_enabled()) {
    fuse_opt_add_arg(&args, "-oattr_timeout=0");
}

Não estou certo de como exatamente attr_timeout se traduz no comportamento do cache de inode do kernel. Mas suponho que uma pergunta semelhante se aplicaria, e. para qualquer sistema de arquivos da rede, que gostaria de poder revalidar os detalhes do inode caso eles tenham sido alterados no servidor de arquivos.

    
por 22.07.2018 / 18:58

Tags