Les propriétés natives définies sont les propriétés dont les valeurs peuvent être récupérées et modifiées. La définition des propriétés natives s'effectue à l'aide de la commande zfs set, selon la procédure décrite à la section Paramétrage des propriétés ZFS ou à l'aide de la commande zfs create, selon la procédure décrite à la section Création d'un système de fichiers ZFS. A l'exception des quotas et des réservations, les propriétés natives définies sont héritées. Pour plus d'informations sur les quotas, reportez-vous à la section Définition des quotas et réservations ZFS.
Certaines propriétés natives définies sont spécifiques à un type de jeu de données. Dans ce cas, le type de jeu de données est mentionné dans la description figurant dans le Table 5–1. Sauf indication contraire, les propriétés s'appliquent à tous les types de jeu de données : aux systèmes de fichiers, aux volumes, aux clones et aux instantanés.
Les propriétés pouvant être définies sont répertoriées dans cette section et décrites dans le Table 5–1.
aclinherit
Pour obtenir une description détaillée, reportez-vous à la section Propriétés ACL.
aclmode
Pour obtenir une description détaillée, reportez-vous à la section Propriétés ACL.
atime
canmount
casesensitivity
checksum
compression
copies
périphériques
dedup
encryption
exec
keysource
logbias
mlslabel
mountpoint
nbmand
normalisation
primarycache
quota
readonly
recordsize
Pour obtenir une description détaillée de cette propriété, reportez-vous à la section Propriété recordsize.
refquota
refreservation
reservation
rstchown
secondarycache
share.smb
share.nfs
setuid
snapdir
version
vscan
utf8only
volsize
Pour obtenir une description détaillée de cette propriété, reportez-vous à la section Propriété volsize.
volblocksize
zoned
xattr
Si la propriété canmount est désactivée (valeur off), le système de fichiers ne peut pas être monté à l'aide de la commande zfs mount, ni de la commande zfs mount–a. Définir cette propriété sur off équivaut à définir la propriété mountpoint sur none, à la différence près que le système de fichiers conserve une propriété mountpoint normale pouvant être héritée. Vous pouvez par exemple définir cette propriété sur la valeur off et définir des propriétés héritées pour les systèmes de fichiers descendants. Toutefois, le système de fichiers parent à proprement parler n'est jamais monté, ni accessible par les utilisateurs. Dans ce cas, le système de fichiers parent sert de container afin de pouvoir définir des propriétés sur le conteneur ; toutefois, le conteneur à proprement parler n'est jamais accessible.
L'exemple suivant illustre la création du système de fichiers userpool avec la propriété canmount désactivée (valeur off). Les points de montage des systèmes de fichiers utilisateur descendants sont définis sur un emplacement commun, /export/home. Les systèmes de fichiers descendants héritent des propriétés définies sur le système de fichiers parent, mais celui-ci n'est jamais monté.
# zpool create userpool mirror c0t5d0 c1t6d0 # zfs set canmount=off userpool # zfs set mountpoint=/export/home userpool # zfs set compression=on userpool # zfs create userpool/user1 # zfs create userpool/user2 # zfs mount userpool/user1 /export/home/user1 userpool/user2 /export/home/user2
Lorsque la propriété canmount est définie sur noauto, le système de fichiers peut uniquement être monté de façon explicite et pas automatique.
Cette propriété indique si l'algorithme de correspondance de nom de fichiers utilisé par le système de fichiers doit être casesensitive (respecter la casse), caseinsensitive (ne pas tenir compte de la casse) ou autoriser une combinaison des deux styles de correspondance (mixed).
Lorsqu'une demande de correspondance ne tenant pas compte de la casse est effectuée sur un système de fichiers défini sur mixed, le comportement est généralement identique à ce qu'il serait sur un système de fichiers ne tenant pas compte de la casse. Toutefois, un système de fichiers doté d'une sensibilité à la casse "mixte" peut contenir des répertoires portant des noms uniques en cas de respect de la casse, mais qui ne sont pas uniques lorsque la casse n'est pas prise en compte.
Par exemple, un répertoire peut contenir des fichiers nommés foo, Foo et FOO. Si une demande de correspondance ne tenant pas compte de la casse est effectuée pour l'une des formes possibles de foo (par exemple foo, FOO, FoO, fOo, etc.), l'algorithme de correspondance sélectionne en tant que correspondance l'un des trois fichiers existants. Il est impossible de prévoir avec certitude quel fichier sera choisi comme correspondance par l'algorithme ; en revanche, il est certain que le même fichier sera choisi comme correspondance pour toutes les formes de foo. Le fichier choisi comme correspondance ne tenant pas compte de la casse pour foo, FOO , foO, Foo, et ainsi de suite, est toujours le même, tant que le répertoire n'est pas modifié.
Les propriétés utf8only, normalization et casesensitivity fournissent également de nouvelles autorisations qui peuvent être attribuées à des utilisateurs non privilégiés par le biais de l'administration déléguée de ZFS. Pour plus d'informations, reportez-vous à la section Délégation d'autorisations ZFS.
A des fins de fiabilité, les métadonnées d'un système de fichiers ZFS sont automatiquement stockées plusieurs fois sur différents disques, lorsque cela est possible. Cette fonction est connue sous le terme anglais de ditto blocks.
Cette version vous permet également de stocker plusieurs copies des données utilisateur par système de fichiers à l'aide de la commande zfs set copies. Par exemple :
# zfs set copies=2 users/home # zfs get copies users/home NAME PROPERTY VALUE SOURCE users/home copies 2 local
Les valeurs disponibles sont 1, 2 et 3. La valeur par défaut est 1. Ces copies constituent un ajout à toute redondance de niveau pool, par exemple dans une configuration en miroir ou RAID-Z.
Stocker plusieurs copies des données utilisateur ZFS présente les avantages suivants :
Cela améliore la rétention des données en autorisant leur récupération à partir d'erreurs de lecture de blocs irrécupérables, comme par exemple des défaillances de média (plus connues sous le nom de bit rot) pour l'ensemble des configurations ZFS.
Cela garantit la sécurité des données, même lorsqu'un seul disque est disponible.
Cela permet de choisir les stratégies de protection des données par système de fichiers et de dépasser les capacités du pool de stockage.
Vous pouvez envisager l'utilisation des blocs "ditto" lorsque vous créez accidentellement un pool non redondant et lorsque vous avez besoin de définir des stratégies de conservation de données.
La propriété dedup détermine si les données en double sont supprimées d'un système de fichiers. Si un système de fichiers a la dédupliquer propriété activée, blocs de données dupliquées sont supprimés simultanément. Par conséquent, seules les données uniques sont stockées et les composants communs sont partagés entre les fichiers.
N'activez pas la propriété dedup sur des systèmes de fichiers résidant sur des systèmes de production avant d'avoir passé en revue les points suivants :
Déterminez si vous pouvez économiser de l'espace grâce à la suppression des doublons. Vous pouvez exécuter la commande zdb –S pour simuler les sommes des gains sur l'activation de dedup potentiels d'espace sur votre pool. Cette commande doit être exécutée sur un lieu silencieux pool. Si la suppression des doublons ne s'appliquent pas à vos données, inutile d'activer cette propriété. Par exemple :
# zdb -S tank Simulated DDT histogram: bucket allocated referenced ______ ______________________________ ______________________________ refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE ------ ------ ----- ----- ----- ------ ----- ----- ----- 1 2.27M 239G 188G 194G 2.27M 239G 188G 194G 2 327K 34.3G 27.8G 28.1G 698K 73.3G 59.2G 59.9G 4 30.1K 2.91G 2.10G 2.11G 152K 14.9G 10.6G 10.6G 8 7.73K 691M 529M 529M 74.5K 6.25G 4.79G 4.80G 16 673 43.7M 25.8M 25.9M 13.1K 822M 492M 494M 32 197 12.3M 7.02M 7.03M 7.66K 480M 269M 270M 64 47 1.27M 626K 626K 3.86K 103M 51.2M 51.2M 128 22 908K 250K 251K 3.71K 150M 40.3M 40.3M 256 7 302K 48K 53.7K 2.27K 88.6M 17.3M 19.5M 512 4 131K 7.50K 7.75K 2.74K 102M 5.62M 5.79M 2K 1 2K 2K 2K 3.23K 6.47M 6.47M 6.47M 8K 1 128K 5K 5K 13.9K 1.74G 69.5M 69.5M Total 2.63M 277G 218G 225G 3.22M 337G 263G 270G dedup = 1.20, compress = 1.28, copies = 1.03, dedup * compress / copies = 1.50
Si le ratio estimé est supérieur à 2, la suppression des doublons est susceptible de vous faire gagner de la place.
Dans l'exemple ci-dessus, le ratio de suppression des doublons est inférieur à 2, si bien que l'activation de dedup n'est pas recommandée.
Assurez-vous que votre système dispose de suffisamment de mémoire pour prendre en charge dedup.
Chaque entrée de table dedup interne a une taille d'environ 320 octets.
Multipliez le nombre de blocs alloués par 320. Par exemple :
in-core DDT size = 2.63M x 320 = 841.60M
Les performances de la propriété dedup sont optimisées lorsque le tableau de suppression des doublons tient en mémoire. Si ce tableau doit être écrit sur le disque, les performances diminuent. Par exemple, la suppression d'un système de fichiers volumineux lorsque l'option de dépuplication est activée entrave considérablement les performances du système si les conditions relatives à la mémoire évoquées plus haut ne sont pas satisfaites.
Quand dedup est activé, l'algorithme de somme de contrôle dedup écrase la propriété checksum. Définir la valeur de propriété sur verify équivaut à spécifier sha256,verify. Si la propriété est définie sur verify et que deux blocs ont la même signature, ZFS effectue une vérification octet par octet avec le bloc existant afin de garantir que les contenus sont identiques.
Cette propriété peut être activée pour chaque système de fichiers. Par exemple :
# zfs set dedup=on tank/home
Vous pouvez utiliser la commande zfs get pour déterminer si la propriété dedup est définie.
Bien que la suppression des doublons soit définie en tant que propriété du système de fichiers, elle s'étend à l'échelle du pool. Par exemple, vous pouvez identifier le ratio de suppression des doublons. Par exemple :
# zpool list tank NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT rpool 136G 55.2G 80.8G 40% 2.30x ONLINE -
La colonne DEDUP indique le nombre de suppressions de doublons effectuées. Si la propriété dedup n'est activée sur aucun système de fichiers ou si la propriété dedup vient d'être activée sur le système de fichiers, le ratio DEDUP est 1.00x.
Vous pouvez utiliser la commande zpool get pour déterminer la valeur de la propriété dedupratio. Par exemple :
# zpool get dedupratio export NAME PROPERTY VALUE SOURCE rpool dedupratio 3.00x -
Cette propriété du pool illustre le nombre de suppressions de doublons de données effectuées dans ce pool.
Vous pouvez utiliser la propriété encryption pour chiffrer les systèmes de fichiers ZFS. Pour plus d'informations, reportez-vous à la section Chiffrement des systèmes de fichiers ZFS.
La propriété recordsize spécifie une taille de bloc suggérée pour les fichiers du système de fichiers.
Cette propriété s'utilise uniquement pour les charges de travail de base de données accédant à des fichiers résidant dans des enregistrements à taille fixe. Le système ZFS ajuste automatiquement les tailles en fonction d'algorithmes internes optimisés pour les schémas d'accès classiques. Pour les bases de données générant des fichiers volumineux mais accédant uniquement à certains fragments de manière aléatoire, ces algorithmes peuvent se révéler inadaptés. La définition d'une valeur recordsize supérieure ou égale à la taille d'enregistrement de la base de données peut améliorer les performances du système de manière significative. Il est vivement déconseillé d'utiliser cette propriété pour les systèmes de fichiers à usage générique. En outre, elle peut affecter les performances du système. La taille spécifiée doit être une puissance de 2 supérieure ou égale à 512 octets et inférieure ou égale à 1 MO. La modification de la valeur recordsize du système de fichiers affecte uniquement les fichiers créés ultérieurement. Cette modification n'affecte pas les fichiers existants.
L'abréviation de la propriété est recsize.
Cette propriété permet de partager des systèmes de fichiers ZFS avec le service Oracle Solaris SMB et d'identifier les options à utiliser.
Quand la propriété est activée, tous les partages qui héritent de la propriété sont repartagés avec leurs options actuelles. Quand la propriété est désactivée, les partages qui héritent de la propriété cessent d'être partagés.Pour obtenir des exemples d'utilisation de la propriété share.smb, reportez-vous à la section Activation et annulation du partage des systèmes de fichiers ZFS.
La propriété volsize spécifie la taille logique du volume. Par défaut, la création d'un volume définit une réservation de taille identique. Toute modification apportée à la valeur de la propriété volsize se répercute dans des proportions identiques au niveau de la réservation. Ce fonctionnement permet d'éviter les comportements inattendus lors de l'utilisation des volumes. L'utilisation de volumes contenant moins d'espace disponible que la valeur indiquée risque, suivant le cas, d'entraîner des comportements non valides et des altérations de données. Ces symptômes peuvent également survenir lors de la modification et notamment de la réduction de la taille du volume en cours d'utilisation. Faites preuve de prudence lorsque vous ajustez la taille d'un volume.
Pour plus d'informations sur l'utilisation des volumes, reportez-vous à la section Volumes ZFS.