Zfs: Attributs de fichier

Je pense qu'il vaut la peine de prendre en charge les attributs Linux standard tels que immuable, ajout uniquement, etc. dans l'espace FS_*_FL, même si vous décidez plus tard d'importer l'outil Solaris pour le même. De nombreux systèmes de fichiers différents sur Linux prennent en charge l'interface lsattr/chattr ioctl() pour définir ces indicateurs, bien que certains systèmes de fichiers traduisent les indicateurs en valeurs sur disque (presque) équivalentes pour leur propre usage.

Il n'est pas impossible d'ajouter de nouveaux attributs à FS_*_FL s'ils sont généralement utiles (je ne sais pas quels attributs Solaris n'a pas), bien que cet espace soit épuisé, ils ne peuvent donc pas être ajoutés bon gré mal gré .

Je suis d'accord, il y a quelques mois, j'ai fait une première incursion pour essayer de prendre en charge les attributs Linux standard. J'ai déterminé à l'époque que immuable, append-only et nodump étaient les seuls attributs communs entre Solaris et Linux. Malheureusement, je n'ai pas pu trouver le temps de finir ce travail mais la branche de développement est disponible. Vous trouverez ci-dessous la liste complète des attributs zfs à titre de référence.

 /*
 * Attributs de niveau de fichier supplémentaires, qui sont stockés
 * dans la moitié supérieure de zp_flags
 */
 #define ZFS_READONLY 0x00000001000000000ull
 #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 0x00000010000000000ull
 #define ZFS_AV_QUARANTINED 0x00000200000000000ull
 #define ZFS_AV_MODIFIED 0x00000040000000000ull
 #define ZFS_REPARSE 0x00000800000000000ull
 #define ZFS_OFFLINE 0x0000100000000000ull
 #define ZFS_SPARSE 0x0000200000000000ull

Comme je l'ai mentionné sur la liste de diffusion, j'ai examiné cela et pensé aux mappages. Voici mes réflexions pour les autres à considérer autant ou aussi peu qu'ils l'entendent :

Mappages évidents :
ZFS_IMMUTABLE <-> FS_IMMUTABLE_FL
ZFS_APPENDONLY <-> FS_APPEND_FL
ZFS_NODUMP <-> FS_NODUMP_FL

Peut-être une bonne idée pour des raisons de compatibilité :
Si ZFS_IMMUTABLE est défini, effacez ZFS_NOUNLINK. Cela permettrait à un utilisateur d'effacer ZFS_NOUNLINK avec : chattr +i FILE ; chattr -i FILE

Idée folle 1 :
Mappez ZFS_READONLY, ZFS_HIDDEN, ZFS_SYSTEM et ZFS_ARCHIVE et le crtime à un utilisateur compatible Samba.DOSATTRIB xattr.

Idée folle 2 :
La définition de FS_TOPDIR_FL sur un répertoire définit une propriété afin que les opérations mkdir() dans ce répertoire créent de nouveaux ensembles de données ZFS. Ce serait utile pour /home, par exemple. Ensuite, vous n'avez pas besoin d'accrocher les modifications ZFS à useradd sous Linux. Et c'est déjà une idée raisonnable de chattr +T /home sur ext[234]. Même si vous n'y connectez pas FS_TOPDIR_FL, l'idée d'une propriété ZFS à cet effet serait toujours utile sur /home.

Bonjour,

y a-t-il des progrès sur ce sujet? J'ai récemment basculé mon serveur multimédia sur ZFS mais je manque la possibilité de définir l'indicateur immuable. Je voudrais "protéger" certains fichiers, existe-t-il une solution de contournement pour définir le drapeau ? Peut-être via un programme externe ? Cela fonctionnerait-il ?

Merci!

@cyberius0 Personne ne travaille actuellement dessus. Mais si quelqu'un le souhaite, je suis tout à fait d'accord.

J'aimerais tenter le coup si quelqu'un m'oriente dans la bonne direction. J'ai besoin de cette fonctionnalité.

+1

L' idée folle 2 de

+1

Il convient de noter que l'interface d'attribut de fichier Linux souffre d'une course TOCTOU qui ne se produit pas sur Solaris. Les outils de l'espace utilisateur sur Solaris et Linux prennent les modifications des attributs de fichier en tant qu'arguments et les attributs de fichier sont stockés dans le noyau et sur le disque en tant que masques de bits, mais les similitudes s'arrêtent là.

Sous Solaris, une liste des valeurs qui changeront, accompagnées de leurs valeurs, est envoyée au noyau. Le fait de prendre le bitmask courant, de le modifier et de le stocker est alors traité sous zp->z_lock. Cela garantit que tous les changements sont atomiques, ce qui est la bonne façon de faire les choses. Sous Linux, la responsabilité des modifications est sous-traitée à l'espace utilisateur. L'utilitaire de l'espace utilisateur obtiendra le masque de bits actuel, apportera les modifications et enverra un nouveau masque de bits qui remplacera l'ancien. Étant donné que l'espace utilisateur ne peut pas verrouiller le fichier contre les modifications, deux threads simultanés touchant des bits différents sur le même fichier peuvent être soit les deux changements, soit un seul changement.

zfsonlinux/zfs#1693 a rendu ZFSOnLinux vulnérable à ce problème en implémentant du code de traduction entre l'interface Linux et l'interface ZFS de Solaris. Heureusement, une modification aussi rapide des attributs de fichier est rare, ce qui explique probablement pourquoi cela n'a pas été détecté lorsque les attributs de fichier ont été implémentés pour la première fois sous Linux. Nous devrions déprécier l'interface Linux en faveur d'une interface atomique comme ce que fait Solaris lorsque nous implémentons nos propres outils de modification d'attributs de fichier. Ceux-ci seront nécessaires pour exposer la gamme complète des attributs de fichier ZFS que nous avons hérités de Solaris.

La prise en charge des mappages évidents a été fusionnée et fera partie de la 0.6.3.

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

Cela ne couvre pas les attributs qui existent sur Linux mais pas Illumos et vice-versa. Étant donné que nous allons devoir les traiter au cas par cas, je pense qu'il est logique de clore cette question. Nous pouvons ouvrir un nouveau problème pour chaque attribut si nécessaire pour discuter des détails de son comportement.

9d31779 Implémenter la prise en charge des attributs de fichier
3b4f425 Refactoriser la vérification des outils automatiques inode_owner_or_capable()

@behlendorf Existe-t-il une documentation ou un manuel répertoriant les attributs pris en charge et ce qu'ils font sur un système ZFS ?