Les propriétés héritées sont des propriétés standard qui peuvent être héritées du projet ou définies explicitement sur le partage. Dans la BUI, il est uniquement possible d'hériter de toutes les propriétés à la fois mais, dans la CLI, vous pouvez sélectionner les propriétés dont vous souhaitez hériter.
Les partages qui font partie d'un projet peuvent avoir des propriétés héritées de paramètres locaux ou d'un projet parent. Par défaut, les partages héritent de toutes les propriétés du projet. Si une propriété est modifiée sur un projet, tous les partages qui héritent de cette propriété sont mis à jour en fonction de la nouvelle valeur. Une fois héritées, ces propriétés possèdent la même valeur que celle du projet parent, à l'exception des propriétés du point de montage et de SMB. Une fois héritées, ces propriétés concatènent les paramètres du projet avec leur propre nom de partage.
La propriété de point de montage correspond à l'emplacement sur lequel le système de fichiers est monté. Elle est valide uniquement pour les systèmes de fichiers.
Les restrictions suivantes s'appliquent à la propriété mountpoint :
Doit impérativement être sous /export
Ne doit pas être en conflit avec un autre partage
Ne doit pas être en conflit avec un autre partage sur le pair du cluster afin que le basculement s'effectue correctement
Lorsqu'il hérite de la propriété mountpoint, le nom actuel attribué à l'ensemble des données est ajouté au paramètre de point de montage du projet et les deux éléments sont liés par une barre oblique ('/'). Par exemple, si le projet "home" possède le paramètre mountpoint /export/home</tt, "home/bob" hérite du point de montage /export/home/bob.
Les partages SMB sont exportés via leur nom de ressource et le point de montage n'est pas visible dans le protocole. Cependant, même les partages qui n'utilisent que le protocole SMB doivent avoir un point de montage unique valide sur l'appareil.
Les points de montage peuvent être imbriqués sous d'autres partages, bien qu'il existe certaines limitations. Pour plus d'informations, reportez-vous à la section Utilisation de l'espace de noms du système de fichiers.
La propriété de lecture seule détermine si le contenu du système de fichiers est en lecture seule. Elle est valide uniquement pour les systèmes de fichiers.
Il est impossible de modifier le contenu d'un système de fichiers en lecture, quels que soient les paramètres du protocole. Cependant, ce paramètre n'empêche pas de renommer, détruire ou modifier les propriétés du système de fichiers. De plus, quand un système de fichiers est en lecture seule, les propriétés du contrôle d'accès ne peuvent pas être modifiées car il faudrait pour cela modifier les attributs du répertoire racine du système de fichiers
La mise à jour de l'heure d'accès à la lecture détermine si l'heure d'accès aux fichiers a été mise à jour à la lecture de ce dernier. Elle est valide uniquement pour les systèmes de fichiers.
Les normes POSIX exigent que l'heure d'accès à un fichier indiquée corresponde exactement l'heure à laquelle le fichier à été lu pour la dernière fois. Il est donc nécessaire d'effectuer des opérations d'écriture sur le système de fichiers sous-jacent même dans le cas d'une charge de travail effectuée principalement en lecture seule. Pour les charges de travail consistant principalement à effectuer des lectures sur un très grand nombre de fichiers, la désactivation de cette propriété peut entraîner une amélioration des performances aux dépens du respect des normes. Ces mises à jour étant regroupées et se produisant de manière asynchrone, leurs effets ne devraient pas être visibles, sauf dans le cas d'une charge très importante.
La propriété de verrouillage obligatoire non bloquant détermine si la sémantique de verrouillage SMB est appliquée sur la sémantique POSIX. Elle est valide uniquement pour les systèmes de fichiers.
Par défaut, les systèmes de fichiers implémentent le comportement d'un fichier en respectant les normes POSIX. Ces normes ne sont absolument pas compatibles avec le comportement requis par le protocole SMB. Pour les partages dans lesquels le protocole principal est SMB, cette option doit toujours être activée. Pour modifier cette propriété, tous les clients doivent être déconnectés puis reconnectés.
La propriété de suppression des doublons de données détermine si les doublons de données sont supprimés. La suppression des doublons est une opération qui s'effectue à l'échelle du pool, basée sur le bloc et qui peut être activée par projet ou par partage.
Pour activer la suppression des doublons cochez la case Suppression des doublons de données dans l'écran des propriétés générales des projets ou des partages. Le taux de suppression des doublons apparaît dans la zone Utilisation de l'écran Tableau de bord de statut. Lorsque la propriété de suppression des doublons est activée, les données écrites sont saisies dans la table de suppression des doublons indexée par la somme de contrôle des données. La suppression des doublons force l'utilisation de la somme de contrôle SHA-256 à fortes propriétés cryptographiques. Les écritures consécutives identifient les doublons de données et seule la copie existante est conservée sur le disque. La suppression des doublons est possible uniquement entre les blocs de même taille et données écrites avec la même taille d'enregistrement. Pour obtenir de meilleurs résultats, utilisez la même taille d'enregistrement que celle de l'application qui traite les données. Pour la transmission de charges de travail, utilisez une grande taille d'enregistrement.
Si vos données ne contiennent aucun doublon, l'activation de la propriété Suppression des doublons de données ajoute du temps système (une somme de contrôle plus intensive au niveau de la CPU et des entrées dans la table de suppression de doublons sur disque) sans offrir aucun avantage. Si vos données contiennent des doublons, l'activation de la propriété Suppression des doublons de données permet à la fois d'économiser de l'espace en stockant une seule copie d'un bloc spécifique, quel que soit le nombre d'occurrences. La suppression des doublons a nécessairement un effet sur les performances puisque le coût du calcul de la somme de contrôle est plus élevé et que les métadonnées de la table de suppression de doublons doivent être accessibles et entretenues.
Notez que la suppression des doublons n'a aucune conséquence sur la taille calculée du partage mais influe sur la quantité d'espace de pool utilisée. Par exemple, si deux partages contiennent le même fichier de 1 Go, la taille indiquée de chaque fichier sera de 1 Go mais la taille totale du pool indiquée sera uniquement de 1 Go et le taux de suppression des doublons sera signalé comme 2x.
Par nature, la suppression des doublons nécessite la modification de la table de suppression des doublons lorsqu'un bloc est en cours d'écriture ou libéré. Si la table de suppression des données ne tient pas dans la DRAM, les écritures et l'espace libéré peuvent entraîner une forte activité de lecture aléatoire à des emplacements où il n'y en avait pas auparavant. Par conséquent, l'activation de cette propriété peut avoir de lourdes conséquences sur les performances. Par ailleurs, dans certains cas (en particulier pour la suppression de partages ou d'instantanés), la dégradation des performances due à l'activation de la suppression des doublons peut être ressentie dans la totalité du pool. En général, il n'est pas conseillé d'activer la suppression des doublons, sauf si vous savez qu'un partage compte un grand nombre de doublons et que la DRAM contient suffisamment d'espace pour que ces doublons de données ainsi que la table servant à les référencer y soient exportés.
Pour déterminer si la suppression des doublons a eu une incidence négative sur les performances, activez analyse avancée puis utilisez Analytics pour mesurer les "opérations ZFS DMU ventilées par type d'objet DMU" et recherchez un taux d'opérations DDT (opérations Data Duplication Table) plus élevé que celui des opérations ZFS. Si cela se produit, l'augmentation des E/S est plus utile à la table de suppression des doublons qu'aux E/S de fichier.
Pour utiliser la suppression des doublons avec chiffrement, n'oubliez pas que seul le standard AES accompagné du mode de chiffrement CCM est compatible avec la suppression des doublons. Pour plus d'informations, reportez-vous à la section Gestion des clés de chiffrement.
La propriété de compression des données détermine si les données sont compressées avant d'être écrites sur le disque. Les partages peuvent éventuellement compresser les données avant de les écrire sur le pool de stockage. Cette propriété permet une meilleure utilisation de l'espace de stockage mais augmente l'utilisation de la CPU. Par défaut, aucune compression n'est effectuée. Si la compression ne produit pas un minimum d'économie d'espace, le disque n'est pas paramétré pour éviter les opérations de décompression inutiles lors de la lecture des données. Avant de choisir un algorithme de compression, nous vous recommandons d'effectuer tous les tests de performances nécessaires et de mesurer le taux de compression atteint.
|
La propriété de somme de contrôle détermine la somme de contrôle utilisée pour les blocs de données. Sur l'appareil, toutes les données du disque font l'objet d'un contrôle par totalisation d'une façon qui permet d'éviter les problèmes habituels (en particulier les lectures et les écritures fantômes). Cela permet au système de détecter les données non valides renvoyées par les périphériques. La somme de contrôle par défaut (fletcher4) est suffisante pour une opération classique, toutefois les utilisateurs peuvent augmenter la force de la somme de contrôle bien que cela augmente la charge de la CPU. Les métadonnées font toujours l'objet d'un contrôle par totalisation à l'aide du même algorithme, de sorte que cela n'affecte que les données utilisateur (fichiers ou blocs LUN).
|
La propriété d'utilisation du périphérique de cache détermine si les périphériques de cache sont utilisés pour le partage. Par défaut, tous les ensembles de données utilisent les périphériques de cache présents sur le système. Les périphériques de cache sont configurés dans le cadre du pool de stockage et fournissent une couche supplémentaire de mise en cache pour permettre un accès à plusieurs niveaux plus rapide. Pour plus d'informations sur les périphériques de cache, reportez-vous à la section Configuration du stockage. Cette propriété ne tient pas compte du fait qu'il existe ou non des périphériques de cache configurés dans le pool de stockage. Par exemple, il est possible que cette propriété soit définie sur "all" même si aucun périphérique de cache n'est présent. Si, dans le futur, vous ajoutez ce type de périphérique, le partage tire automatiquement parti de cette amélioration des performances. Cette propriété n'affecte pas l'utilisation du cache principal (DRAM).
|
La propriété de décalage d'écriture synchrone détermine le comportement lors du traitement d'écritures synchrones. Par défaut, le système optimise les écritures synchrones pour la latence, ce qui permet au périphérique de journal de fournir des réponses plus rapidement. Dans un environnement comptant plusieurs systèmes de fichiers non joints, cela peut entraîner des conflits d'utilisation sur les périphériques de journal et ainsi, augmenter la latence pour l'ensemble des consommateurs. Même quand plusieurs systèmes de fichiers nécessitent une sémantique synchrone, il peut arriver que certains systèmes de fichiers soient plus sensibles que d'autres à la latence.
Par exemple, il arrive souvent qu'une base de données ait un journal distinct. Le journal est très sensible à la latence. La base de données nécessite elle aussi une sémantique synchrone, mais elle consomme davantage de bande passante et n'est pas sensible à la latence. Dans cet environnement, vous pouvez définir cette propriété sur "débit" dans la base de données principale et laisser le système de fichiers de journal sur "latence" pour améliorer les performances de manière significative. Ce paramètre change de comportement même si aucun périphérique de journal n'est présent (les conséquences étant moins graves dans ce cas).
Le paramètre de décalage d'écriture synchrone peut être contourné par Oracle Intelligent Storage Protocol. Au lieu d'utiliser le décalage d'écriture dans le système de fichier, Oracle Intelligent Storage Protocol peut utiliser la valeur de décalage d'écriture fournie par le client Oracle Database NFSv4. La valeur de décalage d'écriture envoyée par le client Oracle Database NFSv4 est uniquement utilisée pour cette requête d'écriture.
|
La propriété de taille des enregistrements de la base de données spécifie une taille de bloc suggérée pour les fichiers du système de fichiers. Cette propriété est valide uniquement pour les systèmes de fichiers et s'utilise pour les charges de travail de base de données accédant à des fichiers résidant dans des enregistrements à taille fixe. Le système 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 taille d'enregistrement 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 d'enregistrement par défaut est de 128 Ko. 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 taille d'enregistrement du système de fichiers affecte uniquement les fichiers créés ultérieurement : les fichiers existants et les données reçues ne sont pas touchés. Si des tailles de blocs supérieures à 128 Ko sont utilisées pour les projets et les partages, la réplication de ces projets ou partages sur des systèmes qui ne prennent pas en charge les tailles de blocs importantes échouera.
Le paramètre de taille des enregistrements de la base de données peut être contourné par le protocole OISP. Au lieu d'utiliser la taille des enregistrements dans le système de fichier, Oracle Intelligent Storage Protocol peut utiliser la valeur de taille de bloc fourni par le client Oracle Database NFSv4. La taille de bloc fournie par le client Oracle Database NFSv4 peut uniquement être appliquée lors de la création de nouveaux fichiers ou d'un nouveau tableau de base de données. Les tailles de bloc des fichiers et tableaux existants ne seront pas modifiées. Pour plus d'informations, reportez-vous à la section Protocole OISP (Oracle Intelligent Storage Protocol).
La propriété de réplication supplémentaire contrôle le nombre de copies stockées dans chaque bloc, indépendamment de toute redondance du pool de stockage. Les métadonnées sont toujours stockées en plusieurs exemplaires, mais cette propriété autorise l'application de ce comportement aux blocs de données. Le pool de stockage tente de stocker ces blocs supplémentaires sur d'autres périphériques, mais la réussite de cette opération n'est pas garantie. De plus, un pool de stockage ne peut pas être importé en cas de perte de la totalité d'un périphérique logique (largeur de bande RAID, pair mis en miroir, etc.). Cette propriété ne remplace pas une réplication adaptée dans le pool de stockage mais permet de rassurer les administrateurs inquiets.
La propriété d'analyse antivirus détermine si le système de fichiers est analysé pour détecter d'éventuels virus. Elle est valide uniquement pour les systèmes de fichiers. Le paramétrage de cette propriété est indépendant de l'état du service d'analyse de virus. Même si le service Analyse antivirus est activé, l'analyse du système de fichiers doit être explicitement activée à l'aide de cette propriété. De même, l'analyse antivirus peut être activée pour un partage spécifique même si le service est désactivé. Pour plus d'informations sur la configuration de l'analyse antivirus, reportez-vous à la section Analyse antivirus.
Lorsque cette propriété est définie, les partages ou les projets ne peuvent pas être détruits. Cela comprend la destruction d'un partage par le biais de clones dépendants, la destruction d'un partage contenu dans un projet ou la destruction d'un package de réplication. Cependant, cela ne concerne pas les partages détruits par le biais des mises à jour de réplication. Si un partage est détruit sur un appareil qui est la source de la réplication, le partage correspondant sur la cible sera détruit, même si cette propriété est activée. Pour détruire un partage, cette propriété doit d'abord être explicitement désactivée au cours d'une étape distincte. Par défaut, cette propriété est désactivée.
Par défaut, la propriété des fichiers ne peut pas être modifiée sauf par un utilisateur root (sur un client adapté ayant l'option d'export root activée). Cette propriété peut être désactivée pour un projet ou un système de fichiers spécifique en désactivant cette propriété. Lorsque que cette propriété est désactivée, la propriété de fichier peut être modifiée par le propriétaire du fichier ou du répertoire, ce qui permet aux utilisateurs "d'abandonner" leurs propres fichiers. Lorsque la propriété est modifiée, tous les bits setuid ou setgid sont éliminés, afin d'empêcher les utilisateurs d'augmenter leurs privilèges par cette opération.