Différences entre les systèmes de fichiers Oracle Solaris ZFS et classiques

• Granularité du système de fichiers ZFS

• Comptabilisation de l'espace disque ZFS

• Montage de système de fichiers ZFS

• Gestion de volumes classique

• Modèle ACL Solaris basé sur NFSv4

Granularité du système de fichiers ZFS

Traditionnellement, les systèmes de fichiers étaient restreints à un périphérique et par conséquent à la taille de ce périphérique. Les créations successives de systèmes de fichiers classiques dues aux contraintes de taille demandent du temps et s'avèrent parfois difficile. Les produits de gestion de volume traditionnels aident à gérer ce processus.

Les systèmes de fichiers ZFS n'étant pas limités à des périphériques spécifiques, leur création est facile et rapide, tout comme celle des répertoires. La taille des systèmes de fichiers ZFS augmente automatiquement dans l'espace disque alloué au pool de stockage sur lequel ils se trouvent.

Au lieu de créer un système de fichier, comme /export/home, pour la gestion de plusieurs sous-répertoires d'utilisateurs, vous pouvez créer un système de fichiers par utilisateur. Vous pouvez facilement définir et gérer plusieurs systèmes de fichiers en appliquant des propriétés pouvant être héritées par le système de fichiers descendant au sein de la hiérarchie.

Pour obtenir un exemple de création d'une hiérarchie de système de fichiers, reportez-vous à la section Création d'une hiérarchie de systèmes de fichiers ZFS.

Comptabilisation de l'espace disque ZFS

Le système de fichiers ZFS repose sur le concept de stockage de pools. Contrairement aux systèmes de fichiers classiques, qui sont mappés vers un stockage physique, tous les systèmes de fichiers ZFS d'un pool partagent le stockage disponible dans le pool. Ainsi, l'espace disponible indiqué par des utilitaires tels que df peut changer alors même que le système de fichiers est inactif, parce que d'autres systèmes de fichiers du pool utilisent ou libèrent de l'espace.

Notez que la taille maximale du système de fichiers peut être limitée par l'utilisation des quotas. Pour obtenir des informations sur les quotas, reportez-vous à la section Définitions de quotas sur les systèmes de fichiers ZFS. Vous pouvez allouer une certaine quantité d'espace disque à un système de fichiers à l'aide des réservations. Pour obtenir des informations sur les réservations, reportez-vous à la rubrique Définition de réservations sur les systèmes de fichiers ZFS. Ce modèle est très similaire au modèle NFS dans lequel plusieurs répertoires sont montés à partir du même système de fichiers (par exemple : /home).

Toutes les métadonnées dans ZFS sont allouées dynamiquement. La plupart des autres systèmes de fichiers pré-allouent une grande partie de leurs métadonnées. Par conséquent, lors de la création du système de fichiers, ces métadonnées ont besoin d'une partie de l'espace disque. En outre, en raison de ce comportement, le nombre total de fichiers pris en charge par le système de fichiers est prédéterminé. Dans la mesure où ZFS alloue les métadonnées lorsqu'il en a besoin, aucun coût d'espace initial n'est requis et le nombre de fichiers n'est limité que par l'espace disponible. Dans le cas de ZFS, la sortie de la commande df -g ne s'interprète pas de la même manière que pour les autres systèmes de fichiers. Le nombre de fichiers (total files) indiqué n'est qu'une estimation basée sur la quantité de stockage disponible dans le pool.

ZFS est un système de fichiers transactionnel. La plupart des modifications apportées au système de fichier sont rassemblées en groupes de transaction et validées sur le disque de façon asynchrone. Tant que ces modifications ne sont pas validées sur le disque, elles sont considérées comme des modifications en attente. La quantité d'espace disque utilisé disponible et référencé par un fichier ou un système de fichier ne tient pas compte des modifications en attente. Ces modifications sont généralement prises en compte au bout de quelques secondes. Même si vous validez une modification apportée au disque avec la commande fsync(3c) ou O_SYNC, les informations relatives à l'utilisation d'espace disque ne sont pas automatiquement mises à jour.

Sur un système de fichiers UFS, la commande du indique la taille des blocs de données au sein du fichier. Sur un système de fichiers ZFS, la commande du indique la taille réelle du fichier, telle qu'elle est stockée sur le disque. La taille prend en compte les métadonnées et la compression. Ces informations vous aident à déterminer l'espace supplémentaire dont vous disposerez si vous supprimez un fichier donné. Par conséquent, même lorsque la compression est désactivée, vous obtenez des résultats différents entre ZFS et UFS.

Lorsque vous comparez la consommation d'espace renvoyée par la commande df avec celle renvoyée par la commande zfs list, n'oubliez pas que df indique la taille du pool et pas seulement la taille des systèmes de fichiers. En outre, df ne reconnaît pas les systèmes de fichiers descendants ni ne détecte la présence d'instantanés. Si des propriétés ZFS telles que la compression et les quotas sont définies sur les systèmes de fichiers, le rapprochement de la consommation d'espace renvoyée par df peut s'avérer difficile.

Considérez les scénarios suivants qui peuvent également avoir un impact sur la consommation d'espace signalée :

• Pour les fichiers de volume supérieur à recordsize, le dernier bloc du fichier est généralement à moitié plein. Lorsque recordsize est défini par défaut sur 128 Ko, environ 64 Ko sont perdus par fichier, ce qui peut avoir un impact considérable. L'intégration de RFE 6812608 permet de remédier à ce problème. Une solution de contournement consiste à activer la compression. Même si vos données sont déjà compressées, la partie non utilisée du dernier bloc sera remplie de zéros et sera compressée sans difficulté.

• Sur un pool RAIDZ-2, chaque bloc consomme au moins 2 secteurs (par blocs de 512 octets) d'informations de parité. L'espace utilisé par les informations de parité n'est pas signalé ; toutefois, il peut varier et représenter un pourcentage beaucoup plus élevé pour les blocs de petite taille, si bien qu'il peut avoir une incidence sur les valeurs d'espace renvoyées. L'impact est plus important lorsque recordsize est défini sur 512 octets, où chaque bloc logique de 512 octets consomme 1,5 Ko (3 fois l'espace). Quelles que soient les données stockées, si une utilisation efficace de l'espace est primordiale, il est recommandé de conserver la valeur par défaut de recordsize (128 KB) et d'activer la compression (sur la valeur par défaut lzjb).

• La commande df n'a pas connaissance des données de fichiers dédupliquées.

Comportement d'espace saturé

La création d'instantanés de systèmes de fichiers est peu coûteuse et facile dans ZFS. Les instantanés sont communs à la plupart des environnements ZFS. Pour plus d'informations sur les instantanés ZFS, reportez-vous au Chapitre 6, Utilisation des instantanés et des clones ZFS Oracle Solaris.

La présence d'instantanés peut entraîner des comportements inattendus lors des tentatives de libération d'espace disque. En règle générale, si vous disposez des autorisations adéquates, vous pouvez supprimer un fichier d'un système de fichiers plein, ce qui entraîne une augmentation de la quantité d'espace disque disponible dans le système de fichiers. Cependant, si le fichier à supprimer existe dans un instantané du système de fichiers, sa suppression ne libère pas d'espace disque. Les blocs utilisés par le fichier continuent à être référencés à partir de l'instantané.

Par conséquent, la suppression du fichier peut occuper davantage d'espace disque car une nouvelle version du répertoire doit être créée afin de refléter le nouvel état de l'espace de noms. En raison de ce comportement, une erreur ENOSPC ou EDQUOT inattendue peut se produire lorsque vous tentez de supprimer un fichier.

Montage de système de fichiers ZFS

Le système de fichiers ZFS réduit la complexité et facilite l'administration. Par exemple, avec des systèmes de fichiers standard, vous devez modifier le fichier /etc/vfstab à chaque fois que vous ajoutez un système de fichiers. Avec ZFS, cela n'est plus nécessaire, grâce au montage et démontage automatique en fonction des propriétés du système de fichiers. Vous n'avez pas besoin de gérer les entrées ZFS dans le fichier /etc/vfstab.

Pour plus d'informations sur le montage et le partage des systèmes de fichiers ZFS, reportez-vous à la section Montage de système de fichiers ZFS.

Gestion de volumes classique

Comme décrit à la section Stockage ZFS mis en pool, ZFS élimine la nécessité d'un gestionnaire de volume séparé. ZFS opérant sur des périphériques bruts, il est possible de créer un pool de stockage composé de volumes logiques logiciels ou matériels. Cette configuration est déconseillée, car ZFS fonctionne mieux avec des périphériques bruts physiques. L'utilisation de volumes logiques peut avoir un impact négatif sur les performances, la fiabilité, voire les deux, et doit de ce fait être évitée.

Modèle ACL Solaris basé sur NFSv4

Les versions précédentes du système d'exploitation Solaris assuraient la prise en charge d'une implémentation ACL reposant principalement sur la spécification d'ACL POSIX-draft. Les ACL POSIX-draft sont utilisées pour protéger des fichiers UFS. Un nouveau modèle ACL basé sur la spécification NFSv4 est utilisé pour protéger les fichiers ZFS.

Les principales différences présentées par le nouveau modèle ACL Solaris sont les suivantes :

• Le modèle est basé sur la spécification NFSv4 et similaire aux ACL de type Windows NT.

• Ce modèle fournit un jeu d'autorisations d'accès plus détaillé.

• Les ACL sont définies et affichées avec les commandes chmod et ls plutôt qu'avec les commandes setfacl et getfacl .

• Une sémantique d'héritage plus riche désigne la manière dont les privilèges d'accès sont appliqués d'un répertoire à un sous-répertoire, et ainsi de suite.

Pour plus d'informations sur l'utilisation des ACL avec des fichiers ZFS, reportez-vous au Chapitre 7, Utilisation des ACL et des attributs pour protéger les fichiers Oracle Solaris ZFS.