31/07/2018

Redox

La création d'un nouveau système d'exploitation à partir de zéro est une tâche ardue, comme en témoigne la lenteur de la progression de GNU Hurd, par exemple.

 Mais il serait difficile de faire valoir que les systèmes existants sont la fin et la fin de tout notre façon d'interagir avec le matériel informatique.

 Au moins certaines des lacunes dans les offres d'aujourd'hui peuvent sans doute être attribuées au langage utilisé pour les mettre en œuvre; C, pour toute sa puissance, a des défauts assez sérieux qui conduisent à des bugs et des failles de sécurité de toutes sortes.

 Il est donc intéressant de voir un nouvel entrant qui utilise le langage Rust, qui est axé sur la sécurité de la mémoire.

 Le résultat est Redox, qui est encore loin d'être prêt pour un usage quotidien, mais peut constituer un contrepoint intéressant pour Linux, les BSD, OS X, Windows et autres.Comme cela a été exposé dans le livre Redox (qui est aussi un travail en cours), Rust a été choisi pour sa mémoire et sa sécurité. Certaines de ces fonctionnalités ont été décrites dans un article de LWN en 2013. 

Les développeurs Redox considèrent ces fonctions de sécurité comme un élément essentiel d'un système d'exploitation moderne, même s'il est basé sur le modèle Unix, beaucoup plus ancien:Cependant, nous avons un avantage: la mémoire forcée et la sécurité du type.

 C'est le côté fort de Rust, un grand nombre de "bugs inattendus" (par exemple, un comportement indéfini) sont éliminés.La conception de Linux et BSD est sécurisée.

 La mise en œuvre ne l'est pas.L'objectif est donc d'éliminer des classes entières de problèmes qui affectent les programmes C, mais l'accent mis sur la sécurité ne s'arrête pas là.  


Contrairement à Linux, Redox a un design de micro-noyau, où une grande partie du code qui réside dans un noyau monolithique comme Linux est déplacé vers l'espace utilisateur.

 Un micro-noyau fournit simplement la gestion des ressources, la communication interprocessus (IPC), la gestion et la planification des processus / threads, les appels système et peu d'autres choses.

 Le résultat est un noyau beaucoup plus petit (16 000 lignes de code pour Redox et prévoit de le réduire davantage) avec une réduction concomitante de la surface d'attaque, ainsi qu'une quantité beaucoup plus faible de code noyau critique à auditer.En Redox, comme dans MINIX, les conducteurs vivent dans l'espace utilisateur, ce qui leur permet de faire beaucoup moins de dégâts en cas de panne.

 Dans les noyaux monolithiques, un pilote incorrect peut planter tout le système car il s'exécute dans l'espace d'adressage du noyau et avec son niveau de privilège.

 Ainsi, pour Redox, les systèmes de fichiers, les pilotes de périphériques, les réseaux, etc. sont tous implémentés dans l'espace utilisateur.Au-delà de cela, Redox a adopté la philosophie «tout est un fichier» d'Unix (qui a été élargie par le Plan 9) et a fait un pas de plus. Dans Redox, tout est une URL (ou, en réalité, un URI), ce qui signifie que l'API est basée sur l'utilisation d'URL pour accéder aux ressources locales et distantes: 

fichiers, protocoles et sites de réseaux, périphériques, etc.La partie "schéma" d'un URI (par exemple "http:" dans une URL Web) est utilisée pour identifier le type de la ressource à laquelle on accède.

 Ceux-ci sont implémentés en tant que schémas Redox, qui peuvent être implémentés dans l'espace utilisateur ou le noyau, bien que l'espace utilisateur soit préféré.

 Les schémas sont en fait des systèmes de fichiers virtuels avec un ensemble d'opérations disponibles qui sont appropriées au type. Comme le note le livre: 

"'Tout est un schéma, identifié par une URL' est plus précis, mais pas très accrocheur."

 Le wiki Redox explique un peu plus en détail comment les URL et les schémas sont utilisés.  
Par exemple, tcp: //10.11.12.13: 80 serait utilisé pour une connexion TCP distante, tandis que le fichier: /apps/terminal/example.txt fait référence à un fichier local.
 Dans la page wiki de mise en réseau, il est fait mention de l'utilisation d'une URL comme tcp: /// 80 pour un serveur web ou ethernet: // 12: 34: 56: 78: 9A: BC / 800 pour recevoir ou envoyer IPv4 (type 800 ) des paquets pour l'adresse MAC spécifiée.Au-dessous des schémas se trouvent des ressources, qui se présentent sous deux formes: de type fichier (c'est-à-dire bloquant et tamponné) et de type socket (c'est-à-dire non bloquant et semblable à un flux).  
Les ressources sont étroitement liées aux systèmes, comme le note le livre:Les ressources sont des schémas ouverts.
 Vous pouvez les considérer comme une connexion établie entre le fournisseur du schéma et le client.Les ressources sont étroitement liées aux systèmes et parfois liées à des systèmes.

 La différence entre eux est subtile, mais cruciale.Bien que le noyau soit l'objet principal du projet actuellement, il y a aussi quelques projets secondaires d'intérêt.
 Pour commencer, ZFS est conçu comme le système de fichiers de choix pour Redox, ce qui signifie écrire une implémentation compatible dans Rust ou adapter la version open-source existante (OpenZFS).
 Il y a un serveur graphique minimal, orbital, basé sur le protocole Wayland. Il y a aussi un éditeur de type vi (Sodium), des jeux, et plus encore.Le code est disponible sur GitHub et a été publié sous licence MIT.
 L'explication du choix de la licence MIT a été quelque peu controversée chez certains partisans de la GPL, mais les développeurs veulent clairement que Redox se propage loin et large-propriétaires des fourchettes et des extensions sont explicitement tolérés. 
 Des images ISO pour différentes cibles sont disponibles, bien qu'il s'agisse d'un autre travail en cours. Le livre a aussi quelques instructions (commençant ici) pour ceux qui veulent construire Redox pour eux-mêmes.
 Un forum de discussion est prévu pour discuter de Redox et de son développement.

 Il y a des lignes directrices et des idées sur les contributions, une page sur les pratiques exemplaires et la liste des problèmes inévitables.

 Les personnes intéressées peuvent suivre le projet en consultant les bulletins d'information «This Week in Redox», bien qu'ils soient plus sporadiques que le nom ne le laisse supposer.

 Le code de conduite est assez vaste et montre clairement l'intention de favoriser une communauté inclusive.

 En bref, il y a beaucoup d'informations disponibles sur Redox, bien qu'il soit quelque peu dispersé. 
Une question que beaucoup poseront est "pourquoi un nouveau système d'exploitation?" 

 Les développeurs Redox ont une réponse qui se résume à l'insatisfaction avec Linux, les BSD, et même MINIX (qui est «le plus en phase avec la philosophie de Redox»).
 Il y a un sentiment «Non inventé ici» admis dans le projet. Mais une chose qui n'est explicitement pas un objectif pour le projet est de remplacer Linux. Une réponse d'un mot ("Non") au "Redox va-t-il remplacer Linux?" question est contenue dans le livre.

C'est probablement une bonne chose pour un certain nombre de raisons. D'une part, le support matériel est une tâche énorme qui risque de ne pas être surmontée sans un énorme effort de la part de nombreuses entreprises, ce que la licence du MIT pourrait rendre difficile. 


 Qu'on le veuille ou non, la nature réciproque de la GPL semble certainement être une force motrice pour l'implication des entreprises dans Linux. C'est également un domaine dans lequel des alternatives plus permissives (les BSD et MINIX) se sont échouées dans une certaine mesure.

Mais il y a aussi d'autres obstacles. Redox a délibérément choisi d'implémenter un sous-ensemble minimal des appels système Linux (et POSIX).  


Cela rendra plus difficile le portage des applications existantes vers Redox. Cela est en partie dû au fait qu'un écosystème d'espace utilisateur basé sur Rust est envisagé, mais le grand nombre d'applications existantes sous licence libre, qui peuvent être difficiles à mettre en communication, pourrait constituer un obstacle majeur à l'adoption de Redox.  

Des problèmes de longue date avec les performances des micro-noyaux (qui nécessitent beaucoup plus de changements de contexte que les noyaux monolithiques) peuvent également faire de Redox une vente difficile pour le segment des serveurs plus lucratif - même si les gains de sécurité sont importants. substantiel.

C'est clairement un projet ambitieux, peut-être même trop ambitieux; Seul le temps nous le dira. Cependant, il vaut la peine de regarder comme une expérience dans plusieurs dimensions.  


La conception du micro-noyau et la mise en œuvre basée sur Rust fourniront des réponses (ou au moins des preuves dans un sens ou dans un autre) à certaines questions qui circulent depuis un certain temps.  

Nous n'avons évidemment pas toutes les réponses du système d'exploitation pour l'avenir, donc plus de données sont nécessaires. Redox pourrait simplement fournir certaines de ces données.

Qu'est-ce que ZFS sous Linux

Qu'est-ce que ZFS sous Linux

Le projet ZFS sur Linux est une implémentation de OpenZFS conçue pour fonctionner dans un environnement Linux. OpenZFS est une plate-forme de stockage exceptionnelle qui englobe les fonctionnalités des systèmes de fichiers traditionnels, des gestionnaires de volumes, etc. avec une fiabilité, des fonctionnalités et des performances constantes dans toutes les distributions. Des informations supplémentaires sur OpenZFS peuvent être trouvées dans l'article OpenZFS wikipedia.Exigences matériellesParce que ZFS a été initialement conçu pour Sun Solaris, il a longtemps été considéré comme un système de fichiers pour les gros serveurs et pour les entreprises qui pouvaient se permettre le matériel le meilleur et le plus puissant disponible. Mais depuis le portage de ZFS vers de nombreuses plateformes OpenSource (les BSD, Illumos et Linux - sous l'organisation faîtière "OpenZFS"), ces exigences ont été abaissées.Les exigences matérielles suggérées sont les suivantes:

    
Mémoire ECC. Ce n'est pas vraiment une exigence, mais c'est fortement recommandé.
    
8 Go de mémoire pour les meilleures performances. Il est parfaitement possible de fonctionner avec 2 Go ou moins (et les utilisateurs le font), mais vous en aurez besoin plus si vous utilisez la déduplication.Dois-je utiliser la mémoire ECC pour ZFS?L'utilisation de la mémoire ECC pour OpenZFS est fortement recommandée pour les environnements d'entreprise où les garanties d'intégrité des données les plus fortes sont requises. Sans mémoire ECC, de rares flips de bits aléatoires causés par des rayons cosmiques ou par une mémoire défectueuse peuvent ne pas être détectés. Si cela devait arriver, OpenZFS (ou tout autre système de fichiers) écrirait les données endommagées sur le disque et serait incapable de détecter automatiquement la corruption.Malheureusement, la mémoire ECC n'est pas toujours prise en charge par le matériel grand public. Et même quand c'est ECC, la mémoire sera plus chère. Pour les utilisateurs à domicile, la sécurité supplémentaire apportée par la mémoire ECC peut ne pas justifier le coût. C'est à vous de déterminer le niveau de protection requis pour vos données.InstallationZFS sous Linux est disponible pour toutes les principales distributions Linux. Reportez-vous à la section de démarrage du wiki pour les liens vers les instructions d'installation pour de nombreuses distributions populaires. Si votre distribution n'est pas répertoriée, vous pouvez toujours créer ZFS sous Linux à partir de la dernière archive officielle.Architectures supportéesZFS sous Linux est régulièrement compilé pour les architectures suivantes: x86_64, x86, aarch64, arm, ppc64, ppc.Noyaux pris en chargeLes notes pour une version donnée de ZFS sur Linux incluront une série de noyaux supportés. Les versions ponctuelles seront marquées comme nécessaire afin de supporter le noyau stable disponible sur kernel.org. Le noyau supporté le plus ancien est 2.6.32 en raison de sa prédominance dans les distributions Enterprise Linux.Systèmes 32 bits et 64 bitsNous vous encourageons fortement à utiliser un noyau 64 bits. ZFS sur Linux va générer des noyaux 32 bits mais vous pouvez rencontrer des problèmes de stabilité.ZFS a été développé à l'origine pour le noyau Solaris qui diffère du noyau Linux de plusieurs manières significatives. Peut-être plus important pour ZFS, il est courant dans le noyau Solaris de faire un usage intensif de l'espace d'adressage virtuel. Cependant, l'utilisation de l'espace d'adressage virtuel est fortement déconseillée dans le noyau Linux. Ceci est particulièrement vrai sur les architectures 32 bits où l'espace d'adressage virtuel est limité à 100M par défaut. L'utilisation de l'espace d'adressage virtuel sur les noyaux Linux 64 bits est également déconseillée, mais l'espace d'adressage est tellement plus grand que la mémoire physique, c'est moins un problème.Si vous vous heurtez à la limite de la mémoire virtuelle sur un système 32 bits, le message suivant s'affiche dans les journaux système. Vous pouvez augmenter la taille de l'adresse virtuelle avec l'option de démarrage vmalloc = 512M.L'allocation de vmap pour la taille 4198400 a échoué: utilisez vmalloc = pour augmenter la taille.Cependant, même après avoir effectué ce changement, votre système ne sera probablement pas entièrement stable. La prise en charge correcte des systèmes 32 bits dépend du fait que le code OpenZFS se détache de sa dépendance à la mémoire virtuelle. Cela prendra du temps à faire correctement mais c'est prévu pour OpenZFS. Cette modification devrait également améliorer l'efficacité avec laquelle OpenZFS gère le cache ARC et permettre une intégration plus étroite avec le cache de pages Linux standard.


Démarrer depuis ZFS
Démarrer à partir de ZFS sous Linux est possible et beaucoup de gens le font. Il y a d'excellentes promenades disponibles pour Debian, Ubuntu et Gentoo.Sélection de noms / dev / lors de la création d'un pool
Il existe différents noms / dev / qui peuvent être utilisés lors de la création d'un pool ZFS. Chaque option a des avantages et des inconvénients, le bon choix pour votre pool ZFS dépend vraiment de vos besoins. Pour le développement et les tests en utilisant / dev / sdX, le nommage est rapide et facile. Un serveur domestique typique peut préférer / dev / disk / by-id / nommer pour plus de simplicité et de lisibilité. Bien que de très grandes configurations avec plusieurs contrôleurs, boîtiers et commutateurs préfèrent probablement le nommage / dev / disk / by-vdev pour un contrôle maximal. Mais à la fin, la façon dont vous choisissez d'identifier vos disques dépend de vous.

    
/ dev / sdX, / dev / hdX: meilleur pour les pools de développement / test
        
Résumé: Le niveau supérieur / dev / names est la valeur par défaut pour la cohérence avec les autres implémentations ZFS. Ils sont disponibles sous toutes les distributions Linux et sont couramment utilisés. Cependant, comme ils ne sont pas persistants, ils ne doivent être utilisés qu'avec ZFS pour les pools de développement / test.
        
Avantages: Cette méthode est facile pour un test rapide, les noms sont courts, et ils seront disponibles sur toutes les distributions Linux.
        
Inconvénients: Les noms ne sont pas persistants et changeront en fonction de l'ordre dans lequel ils sont détectés. L'ajout ou le retrait de matériel pour votre système peut facilement entraîner une modification des noms. Vous devez ensuite supprimer le fichier zpool.cache et réimporter le pool en utilisant les nouveaux noms.
        
Exemple: zpool créer un réservoir sda sdb

    
/ dev / disk / by-id /: Meilleur pour les petits pools (moins de 10 disques)
        
Résumé: Ce répertoire contient des identifiants de disque avec plus de noms lisibles par l'homme. L'identificateur de disque comprend généralement le type d'interface, le nom du fournisseur, le numéro de modèle, le numéro de série du périphérique et le numéro de partition. Cette approche est plus conviviale car elle simplifie l'identification d'un disque spécifique.
        
Avantages: Bien pour les petits systèmes avec un seul contrôleur de disque. Parce que les noms sont persistants et garantis de ne pas changer, peu importe comment les disques sont attachés au système. Vous pouvez les sortir tous, les mélanger au hasard sur le bureau, les remettre n'importe où dans le système et votre piscine sera automatiquement importée correctement.
        
Inconvénients: La configuration des groupes de redondance en fonction de l'emplacement physique devient difficile et sujette aux erreurs.
        
Exemple: zpool créer un réservoir scsi-SATA_Hitachi_HTS7220071201DP1D10DGG6HMRP

    
/ dev / disk / by-path /: Bon pour les grands pools (plus de 10 disques)
        
Résumé: Cette approche consiste à utiliser des noms de périphériques qui incluent la disposition de câble physique dans le système, ce qui signifie qu'un disque particulier est lié à un emplacement spécifique. Le nom décrit le numéro de bus PCI, ainsi que les noms de boîtier et les numéros de port. Ceci permet le plus de contrôle lors de la configuration d'un grand pool.
        
Avantages: L'encodage de la topologie de stockage dans le nom n'est pas seulement utile pour localiser un disque dans les grandes installations. Mais cela vous permet également de configurer explicitement vos groupes de redondance sur plusieurs adaptateurs ou boîtiers.
        
Inconvénients: Ces noms sont longs, encombrants et difficiles à gérer pour un être humain.
        
Exemple: zpool créer un réservoir pci-0000: 00: 1f.2-scsi-0: 0: 0: 0 pci-0000: 00: 1f.2-scsi-1: 0: 0: 0

    
/ dev / disk / by-vdev /: Meilleur pour les grands pools (plus de 10 disques)
        
Résumé: Cette approche fournit un contrôle administratif sur la dénomination des périphériques à l'aide du fichier de configuration /etc/zfs/vdev_id.conf. Les noms des disques dans les JBOD peuvent être générés automatiquement pour refléter leur emplacement physique par des ID de boîtier et des numéros d'emplacement. Les noms peuvent également être attribués manuellement en fonction des liens de périphériques udev existants, y compris ceux dans / dev / disk / by-path ou / dev / disk / by-id. Cela vous permet de choisir vos propres noms significatifs pour les disques. Ces noms seront affichés par tous les utilitaires zfs afin de pouvoir clarifier l'administration d'un grand pool complexe. Voir les pages de manuel vdev_id et vdev_id.conf pour plus de détails.
        
Avantages: Le principal avantage de cette approche est qu'elle vous permet de choisir des noms significatifs lisibles par l'homme. Au-delà de cela, les avantages dépendent de la méthode de nommage utilisée. Si les noms sont dérivés du chemin physique, les avantages de / dev / disk / by-path sont réalisés. D'un autre côté, l'aliasing des noms basés sur les identifiants de lecteurs ou les WWN présente les mêmes avantages que l'utilisation de / dev / disk / by-id.
        
Inconvénients: Cette méthode repose sur la configuration d'un fichier /etc/zfs/vdev_id.conf correctement configuré pour votre système. Pour configurer ce fichier, veuillez vous référer à la section Configurer le fichier /etc/zfs/vdev_id.conf. Comme pour les avantages, les inconvénients de / dev / disk / by-id ou / dev / disk / by-path peuvent s'appliquer selon la méthode de nommage utilisée.
        
Exemple: zpool créer un miroir de réservoir A1 B1 miroir A2 B2

30/07/2018

Solaris 'health' driver



Solaris 'health' driver



This is the home page for the solaris "health" driver, a motherboard
temperature and fan speed monitor, for motherboards with the WinBond "w83781d"
family of enviromental monitor chips.

It is inspired by the
l*nux "health" driver, by
David Ludlow. However, it shares no code with that driver (apart from one
main similar data 'struct'), due to Solaris's vastly different driver API.


[I spelled it odd so that search engines dont misdirect people to this
page. But only changed it sept 20th, 2001. sorry folks.]



Using the driver



Right now, all you have to do is basicallly

(download the source code file)
tar xvf health.tar
cd health
make
make install


and you are done. One of these days, i might get around to making a pkg
for it. It's more likely to happen if you email and bug me about it :-)

Once the driver is installed, you can then use /usr/local/bin/printhealth,
to look at the temperature values and fanspeeds that your motherboard knows
about. The chip we talk to thinks it knows about three temperature gauges, and
three fanspeeds. You motherboard may or may not actually have all of
its sensors hooked up to something.
For example, this is the result on an ASUS P2B motherboard:

cyteen$ printhealth 
temperature  #0 - 25.000000C, 77.000000F
temperature  #1 - 208.000000C, 406.400000F
temperature  #2 - 208.000000C, 406.400000F
fan #0: 0.000000
fan #1: 10384.615385
fan #2: 0.000000
Vcore voltage is 2.050000


"temperature #1" and "#2" can reasonably be assumed to not be valid :-)
Sometimes you will see some apparently valid temperature readings, and you
will have no idea what they are for. One of them is probably an "ambient
temperature" sensor, or "motherboard temperature". Check with what your
BIOS says your CPU temperature is, and match it with the appropriate
temperature #

Additionally, while the speed for fan1 may not be accurate, you can at
least see it is working. If you want to set up a monitor for fan failures,
just check for if the fanspeed is less than 500. Or possibly just see if
it is equal to 0.000000

Latest download


The latest source code can be downloaded now.
Last updated July 4rd, 2001

Solaris 9+ warning!

You may need to change 'parent="isa"' to 'class="root"' in health.conf.
Or alternatively, 'parent="i86pc"'.
But if it works for you as-is, dont worry about it.


Compatibility list


At this point in time, the following motherboards seem to be compatible
with this driver:
  • ABit BP6
  • ASUS P2B,P2B-D (temp0=cpu)
  • ASUS P5A (temp0=motherboard, temp1=cpu)
  • Chaintech 6BTM
  • Gigabyte 6BXD
  • SuperMicro P4DC6 (w83627hf chip) (temp0=mb,fan0=cpu1fan, fan1=cpu0fan)
  • SuperMicro P6DBE
  • SuperMicro P6DBU
  • SuperMicro P6DGE
  • Tyan 2886 (temp0==cpu, temp1="ambient"; no fan data)
  • AS Rock K7VT2 (temperature readings only)
If you know of any other motherboards that it works with, please let me know, and I'll add it to the list!

Future

At some point, I would like to:
1. Fix the fanspeed to be more accurate
2. integrate more with David's version, so that a common "printhealth" program can be used.

Unfortunately, at this time, David likes to use floating point in the kernel, which Solaris does not allow.

[later note: i hear David has sinced changed this. But I need encouragement to fix up the code!]

Derivative drivers

Gerhard Strangar was nice enough to put together a driver mod for those folks who have a WinBond chip on the other side of an "SMBus". For example, on a Gigabytes 7IXE-4 motherboard. You may download his 'ghealth' source code here. Read the enclosed README file for what to do with it, and some limitations of the driver.

At some point, I would "like" to merge the two drivers together. but right now, I'm too busy working on Utah-GLX to do that sort of thing :-)


24/07/2018

Le système de fichiers révolutionnaire de Solaris 10

Le système de fichiers révolutionnaire de Solaris 10 offre une capacité pratiquement illimitée, une intégrité des données prouvable et une administration quasi nulle.

La plupart des administrateurs système prennent les limitations des systèmes de fichiers actuels dans la foulée. Après tout, les systèmes de fichiers sont ce qu'ils sont: vulnérables à la corruption de données silencieuse, brutale à gérer, et extrêmement lente.



ZFS, le nouveau système de fichiers dynamique du système d'exploitation Solaris 10 de Sun (SE Solaris) , vous fera oublier tout ce que vous pensiez savoir sur les systèmes de fichiers. ZFS sera disponible sur toutes les plates-formes prises en charge par Solaris 10 et toutes les applications existantes fonctionneront avec. En outre, ZFS complète le portefeuille de gestion du stockage de Sun, y compris le logiciel Sun StorEdge QFS , idéal pour le partage de données professionnelles.
"Si vous êtes prêt à prendre en charge toute la pile logicielle, il y a beaucoup d'innovation possible." 

Jeff Bonwick 
Ingénieur 
éminent Architecte en chef de ZFS 
Sun Microsystems, Inc.
«Nous avons tout repensé et nous l'avons réaménagé», explique Jeff Bonwick, ingénieur distingué de Sun et architecte en chef de ZFS. "Nous avons jeté 20 ans de vieille technologie qui était basée sur des hypothèses qui ne sont plus vraies aujourd'hui."

ZFS est pris en charge sur les plates-formes SPARC et x86. 

Plus important encore, ZFS est neutre en termes d'endian. 
Vous pouvez facilement déplacer des disques d'un serveur SPARC vers un serveur x86. 
Aucune des deux architectures ne paye une taxe d'échange d'octets en raison de la technologie «adaptative endian-ness» en instance de brevet de Sun, qui est unique à ZFS. Et vous n'avez pas à vous soucier de la migration. Sun continue de prendre en charge le système de fichiers UFS.

ZFS répond aux besoins d'un système de fichiers pour tout, des ordinateurs de bureau aux centres de données. Conçu en pensant à l'administrateur, ZFS est le seul système de fichiers autoguérissant et autogéré. CA offre:
  • Administration simple
    ZFS automatise et consolide les concepts complexes d'administration du stockage, en réduisant les frais administratifs de 80%.
  • Intégrité des données garantie
    ZFS protège toutes les données avec des sommes de contrôle de 64 bits qui détectent et corrigent la corruption des données silencieuses.
  • Une évolutivité illimitée
    En tant que premier système de fichiers 128 bits au monde, ZFS offre 16 milliards de milliards de fois la capacité des systèmes 32 ou 64 bits.
  • Performances
    fulgurantes ZFS est basé sur un modèle d'objet transactionnel qui supprime la plupart des contraintes traditionnelles sur l'ordre des E / S émettrices, ce qui entraîne d'énormes gains de performance.

Tout sur Solaris 10 sur Sun.com

Le système d'exploitation Solaris 10, la prochaine version de la plate-forme UNIX leader du secteur, intègre de puissantes nouvelles fonctionnalités pour offrir des niveaux extrêmes de performance, de disponibilité et de sécurité. ZFS dans le système d'exploitation Solaris 10 complète le portefeuille de gestion du stockage existant de Sun, y compris le logiciel Sun StorEdge QFS, qui est idéal pour accéder aux données professionnelles dans un environnement partagé. En plus du système de fichiers ZFSdécrit dans cet article, le système d'exploitation Solaris 10 inclut ces technologies révolutionnaires:  








  • La technologie N1 Grid Containers offre une approche révolutionnaire de la virtualisation du système et de l'utilisation des ressources.  
     











  • DTrace est un cadre de traçage dynamique complet qui répond de manière concise aux questions sur le comportement du système.  
     











  • Solaris 10 inclut également une technologie qui permet d'exécuter une gamme d'applications Linux à des vitesses quasi-natives.  
     











  • Les capacités Predictive Self-Healing du système d'exploitation Solaris 10 permettent aux systèmes Sun de prévoir avec précision les défaillances des composants et de résoudre les problèmes.



  • ZFS atteint ses performances impressionnantes grâce à un certain nombre de techniques:
    • Répartition dynamique sur tous les périphériques pour optimiser le débit
    • La conception de copie-à-écriture rend la plupart des écritures de disque séquentielles
    • Des tailles de blocs multiples, choisies automatiquement pour correspondre à la charge de travail
    • Priorité d'E / S explicite avec la planification d'échéance
    • Tri et agrégation d'E / S globalement optimales
    • Flux de prélecture indépendants multiples avec détection automatique de la longueur et de la foulée
    • Instantanés de lecture / écriture illimités et instantanés
    • Opérations de répertoire parallèles et à temps constant.
    Tout comme il soulage considérablement la souffrance des administrateurs système, ZFS offre un soulagement pour les résultats de votre entreprise. Étant donné que ZFS est construit au-dessus des pools de stockage virtuels 

    (contrairement aux systèmes de fichiers traditionnels qui nécessitent un gestionnaire de volumes distinct),
     la création et la suppression de systèmes de fichiers sont beaucoup moins complexes. Non seulement cela élimine le besoin de payer pour des licences de gestionnaire de volume et permet des contrats de support unique, mais cela réduit les coûts d'administration et augmente l'utilisation du stockage.

    ZFS apparaît aux applications comme un système de fichiers POSIX standard - aucun portage n'est requis. Mais pour les administrateurs, il présente un modèle de stockage groupé qui élimine le concept ancien de volumes, ainsi que tous les problèmes de gestion de partition, de provisionnement et de dimensionnement de système de fichiers associés. Des milliers, voire des millions, de systèmes de fichiers peuvent tous provenir du pool de stockage commun de ZFS, chacun ne consommant que l'espace dont il a besoin. La bande passante d'E / S combinée de tous les périphériques de ce pool de stockage est toujours disponible pour chaque système de fichiers.

    Entrez dans la piscine

    Avec les volumes traditionnels, le stockage est fragmenté et échoué. Avec le pool de stockage commun de ZFS, il n'y a pas de partitions à gérer. La bande passante d'E / S combinée de tous les périphériques d'un pool de stockage est toujours disponible pour chaque système de fichiers.

    Délivrer une administration quasi nulle

    Deux des objectifs de Sun avec ZFS étaient de supprimer de nombreux concepts complexes d'administration de stockage et d'automatiser de nombreuses tâches administratives courantes.
    Par exemple, la création d'un pool de stockage, la création d'un pool ou l'ajout ou la suppression d'un système de fichiers peuvent se faire à l'aide d'une seule commande simple - au lieu du processus multi-étapes ( format, newfs, edit/etc/vfstabet ainsi de suite) .

    Considérez ce cas: Pour créer un pool, pour créer trois systèmes de fichiers, puis pour développer le pool - 5 étapes logiques - 5 commandes ZFS simples sont requises, par opposition à 28 étapes avec un système de fichiers traditionnel et un gestionnaire de volumes.

    De plus, ces commandes sont toutes constantes et complètes en quelques secondes. Les systèmes de fichiers traditionnels et les volumes prennent souvent des heures à configurer. Dans le cas ci-dessus, ZFS réduit le temps nécessaire pour effectuer les tâches de 40 minutes à moins de 10 secondes.

    L'interface de ligne de commande de ZFS simplifie considérablement l'administration. Il est axé sur les tâches, laissant les administrateurs exprimer les tâches qu'ils veulent accomplir au lieu de devoir mémoriser ou rechercher des commandes cryptées.

    «Vous n'avez pas à vous soucier des détails de vos disques, de votre stockage ou de vos systèmes de fichiers», explique M. Bonwick. "Vous ajoutez des disques à votre pool de stockage, les systèmes de fichiers consomment automatiquement l'espace dont ils ont besoin et les administrateurs n'ont pas besoin de s'impliquer.
    «Nous voulions concevoir un système intégré à partir de zéro, et si vous êtes prêt à utiliser l'ensemble du logiciel, il y a beaucoup d'innovation possible.

    Prendre les devoirs de l'intégrité des données

    Les données peuvent être corrompues de plusieurs façons, comme une erreur système ou une coupure de courant inattendue, mais ZFS supprime cette peur de l'inconnu. ZFS empêche la corruption des données en conservant des données cohérentes à tout moment. Toutes les opérations sont transactionnelles. Cela non seulement maintient la cohérence, mais supprime également presque toutes les contraintes sur l'ordre d'E / S et permet aux changements de réussir ou échouer dans son ensemble.

    Toutes les opérations sont également copy-on-write. Les données en direct ne sont jamais écrasées. ZFS écrit des données dans un nouveau bloc avant de modifier les pointeurs de données et de valider l'écriture. La copie sur écriture offre plusieurs avantages:

    • Etat sur disque toujours valide
    • Sauvegardes cohérentes et fiables
    • Rétablissement des données à un moment donné

    «Nous validons la totalité de la pile d'E / S, du début à la fin, sans aucune conjecture, c'est une intégrité des données prouvable», explique M. Bonwick.
    Les administrateurs n'auront plus jamais à exécuter des procédures de récupération laborieuses, par exemple fsck, même si le système est fermé de façon impropre. 
    En fait, les ingénieurs de Solaris Kernel, Bill Moore et Matt Ahrens, ont soumis ZFS à plus d'un million d'accidents violents et forcés au cours de leurs tests. ZFS n'a jamais perdu l'intégrité des données ou a fui un seul bloc.

    En outre, ZFS est le seul système de fichiers qui effectue des sommes de contrôle 64 bits de bout en bout sur toutes les données afin d'éviter la corruption de données silencieuse. Lorsque des données sont lues, la somme de contrôle est vérifiée pour s'assurer que les données que l'application a écrites sont celles qui sont renvoyées.

    «Le coût de la réalisation d'une somme de contrôle n'est plus prohibitif: brûler un petit pourcentage du processeur pour savoir que les données sont intactes est un prix que les administrateurs seraient prêts à payer», explique Moore.

    Dans le cadre de la quête de Sun pour construire des systèmes véritablement autoréparables (voir la fonctionnalité Sun.com du 7 septembre ), ZFS peut auto-soigner les données dans une configuration miroir ou RAID. Lorsqu'une copie est endommagée, ZFS la détecte via la somme de contrôle et utilise une autre copie pour la réparer.

    Aucun produit concurrent ne peut le faire. Les miroirs traditionnels ne peuvent gérer qu'une défaillance totale d'un périphérique.

    Ils n'ont pas de sommes de contrôle, donc ils n'ont aucune idée quand un appareil retourne de mauvaises données. 

    Ainsi, même si les miroirs répliquent des données, ils n'ont aucun moyen d'en tirer parti. En revanche, les sommes de contrôle de bout en bout dans ZFS lui permettent de trouver et de corriger automatiquement les mauvais blocs - avec une certitude de neuf neuf.

    Créer une immense capacité

    Les ingénieurs de Sun se sont demandé si les capacités 64 bits des systèmes de fichiers actuels continueront à suffire au cours des 10 à 20 prochaines années. Leur réponse était non. 

    Si la loi de Moore tient, dans 10 à 15 ans, les gens auront besoin d'un 65e bit. En tant que système 128 bits, ZFS est conçu pour prendre en charge plus de stockage, plus de systèmes de fichiers, plus d'instantanés, plus d'entrées de répertoire et plus de fichiers que ce qui peut éventuellement être créé dans un avenir prévisible.




    AUR Archlinux FR

    AUR Archlinux FR

    ArchwikiFR Accueil Forum Wiki Bugs Paquets AUR Télécharger Planète ...

    Derniers évènements :