Cette section décrit les nouvelles fonctions et les améliorations du SE Solaris 10 version 3/05 liées aux systèmes de fichiers, par rapport à la distribution initiale du SE Solaris 9 en mai 2002.
Cette fonction est nouvelle dans le programme pilote de Software Express. Dans Solaris Express 8/04, NFS version 4 devient le système par défaut. Cette fonction est incluse dans la version 3/05 de Solaris 10.
Solaris 10 inclut l'implémentation Sun du protocole d'accès aux fichiers distribués NFS version 4. Cette version est la suite logique de l'évolution du NFS. Le protocole NFS version 4, défini dans le document RFC 3530, a été développé avec l'appui du groupe IETF. Cette version est conçue pour être neutre tant au niveau du fournisseur que de celui du système d'exploitation.
NFS version 4 combine les protocoles d'accès aux fichiers, de verrouillage de fichier et de montage en un seul protocole unifié afin de simplifier les transferts via un pare-feu et d'améliorer la sécurité. L'implémentation sur Solaris du NFS version 4 est entièrement intégrée à Kerberos V5 (également appelé SEAM), permettant ainsi de garantir l'authentification, l'intégrité et la confidentialité. NFS version 4 permet également la négociation des types de sécurité à utiliser entre le client et le serveur. Grâce à cette fonction, le serveur peut proposer différents types de sécurité aux différents systèmes de fichiers.
L'implémentation sur Solaris de la fonction NFS version 4 inclut la délégation, technique par laquelle le serveur délègue la gestion d'un fichier au client. Cette technique permet de réduire le nombre d'opérations aller-retour car le client est assuré qu'aucune modification ne sera effectuée sans que le serveur ne l'en informe. Le protocole propose aussi la composition d'opérations, qui permet de combiner plusieurs opérations en une seule requête “over-the-wire”.
Pour plus d'informations sur NFS version 4, reportez-vous au chapitre 6, “Accessing Network File Systems (Reference),” du System Administration Guide: Network Services .
Cette fonction a été introduite dans Solaris Express version 4/04 et dans Solaris 9 version 9/04.
La consignation est maintenant activée par défaut pour tous les systèmes de fichiers UFS sauf dans les conditions suivantes :
Lorsque la consignation est explicitement désactivée.
Si l'espace du système de fichiers est insuffisant pour le journal.
Dans les précédentes versions de Solaris, il fallait activer la consignation UFS manuellement.
La consignation UFS rassemble en une transaction toutes les modifications des métadonnées composant une opération UFS complète. Les ensembles de transactions sont enregistrés dans un journal sur le disque puis appliqués aux métadonnées du système de fichiers UFS actuel.
La consignation UFS présente deux avantages :
Un système de fichiers déjà consistant , du fait de l'existence du journal de transaction, peut vous éviter d'avoir à exécuter la commande fsck après une panne système ou un arrêt anormal.
Née avec la version Solaris 9 12/02, la consignation UFS permet d'améliorer ou de dépasser le niveau de performance des systèmes de fichiers sans consignation. Cette amélioration est rendue possible par le fait qu'un système de fichiers avec consignation permet de convertir plusieurs mises à jour des mêmes données en une seule mise à jour. Ceci permet de limiter le nombre d'opérations de disques nécessaires.
Pour plus d'informations, reportez-vous au document “What’s New in File Systems in the Solaris 10 Release?” du System Administration Guide: Devices and File Systems. Consultez aussi la page de manuel mount_ufs(1M).
Cette fonction est nouvelle dans le programme pilote de Software Express et dans la version 12/03 de Solaris 9. Cette fonction est incluse dans la version 3/05 de Solaris 10.
Les améliorations indiquées ci-dessous ont optimisé les performances du client NFS.
Les restrictions concernant les tailles des transferts par câble ont été modérées. Désormais, la taille du transfert dépend des possibilités du transport sous-jacent. Par exemple, la limite du transfert NFS pour le protocole UDP est toujours de 32 Ko. Cependant, TCP étant un protocole de transmission ne possédant pas les limites de datagramme UDP, les tailles maximales de transfert via TCP ont été augmentées à 1 Mo.
Auparavant, toutes les requêtes d'écriture étaient numérotées par le client NFS et le serveur NFS. Le client NFS a été modifié pour permettre à une application d'émettre des écritures simultanées, ainsi que des lectures et des écritures simultanées, vers un fichier unique. Vous pouvez activer cette fonctionnalité sur le client à l'aide de l'option forcedirectio mount. Lorsque vous utilisez cette option, vous activez cette fonctionnalité pour tous les fichiers situés dans le système de fichiers monté. Vous pouvez également l'activer sur un seul fichier du client à l'aide de l'interface directio. () Vous remarquerez que les écritures vers les fichiers sont numérotées si cette fonctionnalité n'est pas activée. D'autre part, si des écritures simultanées ou des lectures et écritures simultanées se produisent, alors la sémantique POSIX n'est plus prise en charge pour ce fichier.
Le client NFS n'utilise plus un nombre excessif de ports UDP. Auparavant, les transferts NFS via UDP utilisaient un port UDP séparé pour chaque requête à traiter. Désormais, par défaut, le client NFS utilise seulement un port UDP réservé. Cependant, cette prise en charge est configurable. Si l'utilisation simultanée de davantage de ports augmente les performances du système par une capacité d'évolution accrue, alors le système peut être configuré pour utiliser plusieurs ports. Cette possibilité reflète la prise en charge NFS via TCP, dotée de ce type de configurabilité depuis qu'elle existe.
Pour de plus amples informations, reportez-vous au System Administration Guide: Network Services .
La prise en charge de systèmes de fichiers multitéra-octets n'est effective que sur les systèmes possédant un noyau de 64 bits. Cette fonction a été introduite dans le programme pilote de Software Express et dans la version 8/03 de Solaris 9. Cette fonction est incluse dans la version 3/05 de Solaris 10.
Solaris 10 permet la prise en charge des systèmes de fichiers UFS de plusieurs téra-octets sur des systèmes fonctionnant avec un noyau Solaris 64 bits. Auparavant, les systèmes de fichiers UFS étaient limités à environ 1 téra-octet (To) sur les systèmes 32 et 64 bits. Toutes les commandes et tous les utilitaires des systèmes de fichiers UFS ont été mis à jour pour prendre en charge les systèmes de fichiers UFS de plusieurs téra-octets.
Vous pouvez d'abord créer un système de fichiers UFS dont la taille est inférieure à 1 To. Grâce à la commande newfs -T, vous pouvez définir la taille du système de fichiers de façon à ce qu'elle atteigne plusieurs téra-octets. Cette commande définit l'I-nœud et la densité du fragment pour qu'ils s'adaptent de manière appropriée à un système de fichiers de plusieurs téra-octets.
La prise en charge d'un système de fichiers UFS de plusieurs téra-octets requiert la disponibilité de LUN de plusieurs téra-octets, sous la forme de volumes Solaris Volume Manager ou de disques physiques de plus d'un To.
Les fonctions des systèmes de fichiers UFS de plusieurs téra-octets sont les suivantes :
création d'un système de fichiers UFS d'une taille maximale de 16 To ;
création d'un système de fichiers d'une taille inférieure à 16 To, pouvant ensuite être augmentée jusqu'à un maximum de 16 To ;
création de systèmes de fichiers de plusieurs téra-octets sur des disques physiques et sur des volumes logiques Solaris Volume Manager ;
activation par défaut de la journalisation UFS sur des systèmes de fichiers de plus d'un téra-octet. Ces systèmes de fichiers bénéficient de l'amélioration des performances de l'activation de la journalisation UFS, et également de la disponibilité de la journalisation car la commande fsck peut ne pas être exécutée lorsque la journalisation est activée.
Vous trouverez ci-dessous les limites des systèmes de fichiers UFS de plusieurs téra-octets.
Vous ne pouvez pas monter de système de fichiers dont la taille est supérieure à 1 To sur un système fonctionnant avec un noyau Solaris 32 bits.
Vous ne pouvez pas démarrer à partir d'un système de fichiers dont la taille est supérieure à 1 To sur un système fonctionnant avec un noyau Solaris 64 bits. Ce qui signifie que vous ne pouvez pas installer de système de fichiers root (/) sur un système de fichiers de plusieurs téra-octets.
Ces systèmes ne prennent pas en charge les fichiers qui font individuellement plus d'un téra-octet.
Le nombre maximum de fichiers par téra-octet dans un système de fichiers UFS est d'un million. Cette limite vise à réduire la durée de la vérification du système de fichiers à l'aide de la commandefsck.
Le quota maximum à définir sur un système de fichiers UFS de plusieurs téra-octets est de 2 To par blocs de 1024 octets.
L'utilisation de la commande fssnap pour créer un instantané d'un système de fichiers UFS de plusieurs téra-octets n'est actuellement pas prise en charge.
Pour plus d'informations, reportez-vous au document “What’s New in File Systems in the Solaris 10 Release?” du System Administration Guide: Devices and File Systems.
Cette fonction est nouvelle dans le programme pilote de Software Express. Cette fonction est incluse dans la version 3/05 de Solaris 10.
Le système de fichiers devfs gère les périphériques dans Software Express. Les utilisateurs accèdent toujours à tous les périphériques via les entrées du répertoire /dev. Ces entrées sont des liens symboliques vers les entrées du répertoire /devices. Le système de fichiers devfs contrôle désormais le contenu du répertoire /devices. Les entrées du répertoire /devices représentent de manière dynamique l'état des périphériques accessibles sur le système. Ces entrées ne demandent aucune administration.
Le système de fichiers devfs fournit les améliorations suivantes :
Les opérations effectuées dans le répertoire /devices entraînent l'ajout des entrées de périphérique. Les entrées de périphérique non utilisées sont séparées.
Les performances d'initialisation du système sont accrues car seules les entrées du périphériques qui sont nécessaires pour initialiser le système sont jointes. Les entrées des nouveaux périphériques sont ajoutées à mesure que l'accès aux périphériques est établi.
Pour plus d'informations, reportez-vous à la page de manuel devfs(7FS).
La prise en charge de disques multitéra-octets n'est disponible que pour les systèmes possédant un noyau de 64 bits. Cette fonction est nouvelle dans le programme pilote de Software Express et dans la version 4/03 de Solaris 9. Cette fonction est incluse dans la version 3/05 de Solaris 10.
Solaris 10 assure une prise en charge des disques d'une capacité supérieure à 1 téra-octet (To) sur des systèmes tournant sur un noyau Solaris 64 bits.
Le label EFI (Extensible Firmware Interface) assure la prise en charge des volumes de disques physiques et logiques. Les systèmes de fichiers UFS sont compatibles avec les labels de disques EFI et permettent de créer un système de fichiers UFS d'une capacité supérieure à 1 To. Cette version inclut des utilitaires de disque mis à jour permettant de gérer des disques d'une capacité supérieure à 1 To.
Cependant, le pilote SCSI, ssd, prend actuellement en charge des disques allant jusqu'à 2 To uniquement. Si une capacité de disque supérieure à 2 To est nécessaire, utilisez un produit de gestion de stockage et de disques tel Solaris Volume Manager pour créer un périphérique plus important.
Pour plus d'informations sur l'utilisation de label de disque EFI, reportez-vous au System Administration Guide: Devices and File Systems . Ce guide contient d'importantes informations et restrictions en ce qui concerne l'utilisation du label de disques EFI avec des logiciels existants.
Dans cette version de Solaris, le logiciel Solaris Volume Manager peut également être utilisé pour gérer des disques d'une capacité supérieure à 1 To. Reportez-vous à la rubrique Prise en charge de volumes de plusieurs téra-octets dans Solaris Volume Manager.
Cette fonction est nouvelle dans le programme pilote de Software Express. Cette fonction est incluse dans la version 3/05 de Solaris 10.
Le nouveau fichier de configuration pour environnement autofs, /etc/default/autofs, propose un autre moyen de configurer les commandes autofs et les démons autofs. Vous pouvez désormais définir dans ce nouveau fichier de configuration les spécifications que vous définiriez sur la ligne de commande. En revanche, contrairement à cette dernière méthode, ce fichier conserve les spécifications, même lors de mises à niveau de votre système. De plus, vous n'avez plus besoin de mettre à jour les fichiers de démarrage critiques pour vous assurer que le comportement existant de votre environnement autofs est conservé.
Les spécifications sont définies à l'aide des mots-clés suivants :
AUTOMOUNTD_ENV permet d'attribuer différentes valeurs aux différents environnements. Ce mot-clé est l'équivalent de l'argument -D de la commande automountd.
AUTOMOUNTD_NOBROWSE active ou désactive la navigation, pour tous les points de montage autofs. Cette commande est l'équivalent de l'argument -n de la commande automountd.
AUTOMOUNTD_TRACE développe chaque appel de procédure à distance (RPC) et l'affiche sur une sortie standard. Ce mot-clé est l'équivalent de l'argument -T de la commande automountd.
AUTOMOUNTD_VERBOSE enregistre les messages d'état sur la console. Il s'agit de l'équivalent de l'argument -v du démon automountd.
AUTOMOUNT_TIMEOUT détermine la durée d'inactivité d'un système de fichiers avant de le démonter. Ce mot-clé est l'équivalent de l'argument -t de la commande automount.
AUTOMOUNT_VERBOSE envoie la notification des montages, démontages et autres événements secondaires autofs. Ce mot-clé est l'équivalent de l'argument -v de la commande automount.
Pour plus d'informations, reportez-vous aux pages de manuel automount(1M) et automountd(1M).
Pour de plus amples informations, reportez-vous au System Administration Guide: Network Services .