Zfs: Atributos de arquivo

Acho que vale a pena oferecer suporte aos atributos padrão do Linux, como imutável, somente acréscimo, etc, no espaço FS _ * _ FL, mesmo se mais tarde você decidir importar a ferramenta Solaris para o mesmo. Muitos sistemas de arquivos diferentes no Linux suportam a interface lsattr / chattr ioctl () para configurar esses sinalizadores, embora alguns sistemas de arquivos traduzam os sinalizadores para valores (quase) equivalentes em disco para seu próprio uso.

Não é impossível adicionar novos atributos ao FS _ * _ FL se eles forem geralmente úteis (não sei quais atributos o Solaris tem que o Linux não), embora esse espaço esteja se esgotando, então eles não podem ser adicionados à toa .

Eu concordo, alguns meses atrás eu fiz uma incursão inicial na tentativa de oferecer suporte aos atributos padrão do Linux. Na época, eu determinei que imutável, somente acréscimo e nodump eram os únicos atributos comuns entre Solaris e Linux. Infelizmente, não consegui encontrar tempo para terminar este trabalho, mas o branch de desenvolvimento está disponível. Abaixo está a lista completa de atributos zfs apenas para referência.

 / *
 * Atributos de nível de arquivo adicionais, que são armazenados
 * na metade superior de zp_flags
 * /
 # define ZFS_READONLY 0x0000000100000000ull
 #define ZFS_HIDDEN 0x0000000200000000ull
 #define ZFS_SYSTEM 0x0000000400000000ull
 #define ZFS_ARCHIVE 0x0000000800000000ull
 #define ZFS_IMMUTABLE 0x0000001000000000ull
 #define ZFS_NOUNLINK 0x0000002000000000ull
 #define ZFS_APPENDONLY 0x0000004000000000ull
 # define ZFS_NODUMP 0x0000008000000000ull
 # define ZFS_OPAQUE 0x0000010000000000ull
 #define ZFS_AV_QUARANTINED 0x0000020000000000ull
 #define ZFS_AV_MODIFIED 0x0000040000000000ull
 #define ZFS_REPARSE 0x0000080000000000ull
 #define ZFS_OFFLINE 0x0000100000000000ull
 #define ZFS_SPARSE 0x0000200000000000ull

Como mencionei na lista de e-mails, examinei isso e pensei nos mapeamentos. Aqui estão meus pensamentos para que outras pessoas considerem, tanto ou tão pouco quanto considerarem adequado:

Mapeamentos óbvios:
ZFS_IMMUTABLE <-> FS_IMMUTABLE_FL
ZFS_APPENDONLY <-> FS_APPEND_FL
ZFS_NODUMP <-> FS_NODUMP_FL

Possivelmente uma boa ideia por motivos de compatibilidade:
Se ZFS_IMMUTABLE estiver sempre definido, limpe ZFS_NOUNLINK. Isso permitiria a um usuário limpar ZFS_NOUNLINK com: chattr +i FILE ; chattr -i FILE

Ideia maluca 1:
Mapeie ZFS_READONLY, ZFS_HIDDEN, ZFS_SYSTEM e ZFS_ARCHIVE e o crtime para um usuário compatível com Samba.DOSATTRIB xattr.

Idéia maluca 2:
Definir FS_TOPDIR_FL em um diretório define uma propriedade para que as operações mkdir () nesse diretório criem novos conjuntos de dados ZFS. Isso seria útil para / home, por exemplo. Então, você não precisa conectar as alterações do ZFS ao useradd no Linux. E é uma ideia razoável já chattr +T /home no ramal [234]. Mesmo que você não conecte FS_TOPDIR_FL a ele, a ideia de uma propriedade ZFS para esse efeito ainda seria útil em / home.

Olá,

há algum progresso neste tópico? Recentemente, mudei meu servidor de mídia para ZFS, mas perco a possibilidade de definir o sinalizador imutável. Gostaria de "proteger" alguns arquivos. Existe alguma solução alternativa para definir o sinalizador? Talvez por meio de um programa externo? Isso funcionaria?

Obrigado!

@ cyberius0 Ninguém está trabalhando nisso no momento. Mas se alguém quiser, estou totalmente a favor.

Eu gostaria de tentar se alguém me apontasse a direção certa. Eu preciso desse recurso.

+1

A Idéia Louca 2 de

+1

Deve-se observar que a interface de atributo de arquivo do Linux sofre de uma corrida TOCTOU que não ocorre no Solaris. As ferramentas do espaço do usuário no Solaris e no Linux aceitam modificações nos atributos do arquivo como argumentos e os atributos do arquivo são armazenados no núcleo e no disco como máscaras de bits, mas as semelhanças terminam aí.

No Solaris, uma lista de quais valores serão alterados, acompanhada de quais serão seus valores, é enviada ao kernel. O ato de pegar a máscara de bits atual, modificá-la e armazená-la é então processado em zp-> z_lock. Isso garante que todas as mudanças sejam atômicas, que é a maneira certa de fazer as coisas. No Linux, a responsabilidade pelas modificações é terceirizada para a área do usuário. O utilitário userland obterá a máscara de bits atual, fará as alterações e enviará uma nova máscara de bits que substituirá a antiga. Visto que o userland não pode bloquear o arquivo contra modificações, duas threads simultâneas tocando em bits diferentes no mesmo arquivo podem ser ambas mudanças ou apenas 1 mudança.

zfsonlinux / zfs # 1693 tornou o ZFSOnLinux vulnerável a esse problema ao implementar algum código de tradução entre a interface do Linux e a interface do ZFS do Solaris. Felizmente, essa modificação rápida de atributos de arquivo é rara, o que é provavelmente porque isso não foi detectado quando os atributos de arquivo foram implementados pela primeira vez no Linux. Devemos descontinuar a interface Linux em favor de uma interface atômica ao longo das linhas do que o Solaris faz quando implementamos nossas próprias ferramentas de modificação de atributo de arquivo. Elas serão necessárias para expor toda a gama de atributos de arquivo ZFS que herdamos do Solaris.

O suporte para os mapeamentos óbvios foi mesclado e fará parte do 0.6.3.

• ZFS_IMMUTABLE <-> FS_IMMUTABLE_FL
• ZFS_APPENDONLY <-> FS_APPEND_FL
• ZFS_NODUMP <-> FS_NODUMP_FL

Isso não cobre atributos que existem no Linux, mas não Illumos e vice-versa. Como teremos que lidar com isso caso a caso, acho que faz sentido encerrar este problema. Podemos abrir um novo problema para cada atributo conforme necessário para discutir os detalhes de como ele deve se comportar.

9d31779 Implementar suporte a atributos de arquivo
3b4f425 Refatorar inode_owner_or_capable () verificação de ferramentas automáticas

@behlendorf Existe documentação ou manual que lista quais atributos são suportados e o que eles fazem em um sistema ZFS?