Pourtant cette apparition timide sur le marché n'est que le prélude d'un véritable raz de marée programmé par les industriels dans les années à venir.
Le monde du logiciel libre est-il prêt à exploiter de façon efficace cette nouvelle technologie ? De nouveaux systèmes de fichiers sont-ils nécessaires et le noyau Linux doit-il être adapté ?
Cette dépêche tente de faire le point sur ces questions et d'évaluer les solutions en présence permettant le support des disques SSD. Un disque dur classique est constitué d'un bras de lecture survolant à très courte distance un plateau rotatif magnétisé et tournant à plusieurs milliers de tours par minute. On voit immédiatement tous les inconvénients de cette technologie: la résistance aux chocs est faible car un contact entre le bras et le plateau doit être évité à tout prix. D'autre part la fiabilité et la consommation énergétique sont mauvaises car il y a des pièces mécaniques à mettre en mouvement. Enfin l'accès aux données est lent car le bras de lecture doit se repositionner au dessus des données avant de pouvoir les lire.
La promesse des disques SSD est de s'affranchir de tous ces défauts d'un seul coup. En basculant vers cette nouvelle technologie qui ne comporte pas de pièces en mouvement on obtiendrait une bonne résistance aux chocs, une fiabilité de haut niveau, une consommation réduite et des temps d'accès sans commune mesure avec les disques durs traditionnels.
Pourtant, outre l'obstacle du prix et de la capacité, il reste un problème important à résoudre afin de profiter pleinement de tous ces avantages. En effet les systèmes de fichiers utilisés jusqu'à présent ont tous été conçus avec les limitations des disques durs en tête et une bonne partie de leur architecture est à revoir.
Actuellement les disques SSD utilisent une interface de communication standard (souvent l'interface SATA) et ils sont vu par le système d'exploitation comme des disques durs classiques. Cela leur permet d'être formaté avec un système de fichiers normal et d'être inséré dans une machine sans problème en dépit du fait qu'ils ne comportent pas des secteurs mais des blocs mémoires.
Néanmoins ces disques SSD à base de mémoire flash sont affligés d'un défaut important puisqu'ils ne supportent qu'un nombre restreint de cycles d'écritures (typiquement de l'ordre de 100000).
Pour faire face à ce problème la technique du "wear levelling" a été développée. Elle consiste schématiquement à enregistrer le nombre d'écritures pour chaque bloc mémoire et à répartir ensuite intelligemment les nouvelles données à écrire de façon à minimiser l'usure de chaque bloc. Des graphiques présentant l'évolution de l'usure d'un disque SSD avec et sans wear levelling sont disponibles sur cette page.
Ce algorithme est implémenté par les constructeurs de disques SSD dans des microcontrôleurs faisant le lien entre la mémoire flash et l'interface sata. C'est certes transparent pour l'utilisateur mais cela signifie que les systèmes de fichiers traditionnels, avec toutes leurs limitations et tout leur code complexe dédié à la minimisation des temps d'accès par le bras de lecture, vont continuer à être utilisé.
Il est donc bien plus efficace de créer des systèmes de fichiers spécialement dédiés aux disques SSD et dialoguant directement avec la puce de mémoire flash sans passer par le microcontrôleur de wear levelling. Cet algorithme est ainsi implémenté directement dans le système de fichiers optimisé pour les SSD.
C'est pourquoi de nombreux développeurs du monde du logiciel libre se sont lancés dans la conception de nouveaux systèmes de fichiers spécialisés dans les disques SSD. Comme il est de mise dans le monde de Linux la compétition est rude et tous les projets aspirent à devenir le Ext3 de demain. A ce stade de développement il peut être intéressant de passer en revue les concurrents en lice et d'évaluer leurs chances respectives.
JFFS et JFFS2
Le système JFFS (Journaling Flash File System), disponible sous licence GPL, a été écrit à l'origine par la société Axis Communications pour l'antique noyau Linux 2.0. Il a été remplacé par JFFS2 qui, sous les auspices de Red Hat et toujours sous licence GPL, a fait son entrée dans le noyau 2.4.10 en septembre 2001. C'est donc un système vraiment mature qui, malgré des limitations que nous verrons par la suite, représente un choix sans risques.
Alors que JFFS première mouture ne fonctionnait qu'avec les mémoires flash NOR et utilisait un mode d'écriture purement circulaire, JFFS2 propose un système bien plus abouti. Tout d'abord la compatibilité avec la mémoire flash NAND, mieux adaptée au stockage d'informations, est assurée. Ensuite les données peuvent être compressées (avec plusieurs algorithmes au choix) ce qui est précieux car les disques SSD ont des capacités de stockage inférieures aux disques durs classiques. Enfin JFFS2 ne fonctionne pas sur un mode d'écriture circulaire comme le faisait JFFS. Avec ce système toutes les écritures s'empilent dans une queue qui écrit en parcourant progressivement tout l'espace disque. C'est une solution simple mais qui implique que toutes les données du disque sont réécrites (même si cela n'était pas nécessaire) et que cela diminue la longévité du disque. Au contraire JFFS2 traite les données par blocs et évite de toucher aux données statiques sur le disque. Comme les blocs mémoires d'un disque SSD sont de grandes tailles (32 Ko ou plus) un ramasse-miettes (garbage collector) est utilisé pour récupérer de la place en fusionnant les données dans des nouveaux blocs afin que les anciens puissent libérer de la place.
Le gros problème de JFFS2 est qu'il a besoin d'examiner tous les blocs mémoires au moment du montage du système de fichiers afin de construire l'index qui est conservé en RAM. Si cette opération n'est que peu pénalisante dans le cas d'un volume de petite taille, elle devient absolument rédhibitoire avec les disques SSD modernes (8 Go et plus).
En définitive JFFS2 est un bon système de fichiers et il est bien adapté aux disques flash de faible capacité mais, du fait de son temps de montage et de l'ancienneté de sa conception, il ne peut plus être considéré comme une solution à privilégier. Le monde du libre a clairement besoin d'un remplaçant.
YAFFS et YAFFS2
Une alternative est le système de fichiers YAFFS (Yet Another Flash File System) développé sous double licence (GPL/commercial) par la société Aleph One. Ce système a été conçu spécifiquement pour la mémoire flash NAND et il est donc a priori bien adapté aux disques SSD. On peut noter d'autre part que YAFFS a été conçu de façon modulaire afin qu'il puisse être utilisé avec d'autres systèmes d'exploitation (par exemple Microsoft WindowsCE).
Une seconde version, YAFFS2, a été introduite afin de respecter la nécessité de n'écrire que le moins de fois possible sur les blocs mémoires et pour permettre l'accès à la mémoire NOR.
YAFFS est presque aussi ancien que JFFS2 puisque l'ouverture du CVS date de mai 2002 mais ce système de fichiers n'a jamais vraiment "décollé" dans le monde du libre. La société Aleph One semble vraiment réserver son produit pour le monde de l'embarqué et n'a jamais vraiment cherché à bâtir une communauté de développement. Un des gros problèmes de YAFFS est le fait qu'il n'est pas intégré dans la branche principale du noyau Linux et qu'il n'y a jamais eu de tentative d'inclusion. Pour pouvoir utiliser ce système il est donc nécessaire de le compiler à partir des sources et la documentation n'est pas vraiment à jour. Bien entendu l'évolution rapide du noyau signifie que les risques de non compatibilité avec un système de fichiers externe comme YAFFS sont élevés comme cet exemple le prouve.
LogFS
Un autre système de fichiers libre (sous licence GPL) et spécialisé dans la mémoire Flash est également développé dans la perspective de l'arrivée en masse des disques durs de type SSD. LogFS est écrit principalement par Jörn Engel et il est basé sur une écriture séquentielle des données (log-structured approach) qui ne nécessite pas de scan complet du volume au montage. Toute la structure du système de fichiers est donc écrite directement dans le disque ce qui accélère considérablement le montage par rapport à JFFS2. Selon Jörn Engel, sur un disque NAND flash d'une capacité de 1 Go, on passe de 3,3 secondes pour le montage sous JFFS2 à 60 millisecondes avec LogFS.
En dépit de ces promesses, l'écriture de LogFS n'est pas réellement terminée et le travail avance lentement puisque Jörn est le seul vrai contributeur. Tant qu'il n'y avait pas de concurrent sérieux pour le titre de "système de fichiers de nouvelle génération pour disques SSD", LogFS pouvait représenter l'avenir (voir cet article de mai 2007). Mais il semble que ce ne soit plus le cas puisqu'un rival très sérieux, UBIFS, vient d'apparaitre récemment.
UBI et UBIFS
UBI (Unsorted Block Images) est une couche d'abstraction présente dans le noyau Linux depuis la version 2.6.22 et qui permet de gérer les périphériques à base de mémoire NAND flash. C'est un équivalent fonctionnel de LVM mais spécialisé dans la mémoire flash. UBI effectue un mappage entre les blocs logiques de la mémoire flash et les blocs physiques. Elle permet la répartition des écritures sur toute la mémoire (wear levelling) et elle tient compte des blocs mémoires défectueux (bad-block handling). La couche gère également la création de volumes UBI qui peuvent être dynamiquement créés, re-dimensionnés ou supprimés. Un fichier PDF complet sur la conception d'UBI est disponible ici.
Comme cette couche UBI est déjà présente dans le noyau il parait éminemment logique de construire un système de fichiers gérant les disques SSD par dessus cette infrastructure afin de profiter de ses avantages et de factoriser le code noyau :
===========================
| Système de fichiers UBIFS |
===========================
|
=====================================
| Couche UBI de factorisation de code |
=====================================
|
=============================
| Couche MTD interne au noyau |
=============================
|
_________________________________
| | | |
====== ===== =========== =========
| NAND | | NOR | | DataFlash | | ECC NOR |
====== ===== =========== =========
Les ingénieurs de la firme Nokia, en collaboration avec l'université de Szeged, ont donc travaillé afin de développer UBIFS (UBI file system) et ont récemment présenté le résultat de leurs efforts sur la liste de diffusion du noyau.
Comme pour LogFS, il a été décidé de conserver sur le disque Flash l'index de la structure du système de fichiers afin d'éviter de lire l'intégralité du disque. L'ennui c'est qu'un scan de tout le disque est quand même nécessaire lors du montage car la couche UBI en a besoin pour attacher le périphérique. Cependant ce scan se contente de lire les en-tête des blocs les temps de boot sont donc bien plus rapides qu'avec JFFS2.
Un autre avantage est qu'UBIFS utilise un cache pour les données (writeback) ce qui permet d'éviter d'écrire les données de façon strictement synchrone. Le gain en performances est absolument ahurissant (write tests gave us ~100 times faster performance which is clearly because of the caching) par rapport à l'écriture synchrone de JFFS2.
Enfin UBIFS, ou plutôt la couche UBI sous-jacente, gère parfaitement le dysfonctionnement des blocs mémoires (courant avec la mémoire flash) que ce soit lors de la création du système de fichiers ou au cours de la vie du système. LogFS est limité à la gestion des mauvais blocs lors de la création et ne peut les gérer par la suite.
Un document détaillé sur le design d'UBIFS est disponible ici.
En conclusion
JFFS2 est âgé et son temps de montage le rend inadapté pour utiliser les disques modernes de grande taille. YAFFS2 est un bon système pour l'embarqué mais il reste relativement obscur et ne vise pas à intégrer Linux. En définitive il ne reste vraiment en lice que LogFS et UBIFS.
Par rapport à son nouveau concurrent LogFS garde l'avantage sur le plan de la compacité du code (environ 8000 lignes contre 11000+30000 pour UBI+UBIFS) et sur le temps de montage. Néanmoins la situation a beaucoup changé et LogFS, qui l'an dernier semblait le candidat le mieux placé pour prendre la place du vénérable JFFS2, a perdu un peu de son éclat depuis l'arrivée d'UBIFS. Ce nouveau système est techniquement plus cohérent puisqu'il s'appuie sur une couche (UBI) déjà présente dans le noyau et les tests semblent montrer que ses performances sont meilleures. Le fait que Nokia soit derrière ce système de fichiers alors que LogFS ne peut compter que sur un seul vrai contributeur est également une indication à prendre en compte en ce qui concerne le rythme de développement.
Bien entendu rien n'est encore joué et il faudra surmonter la redoutable épreuve de l'acceptation dans la branche principale avant que nous puissions y voir plus clair dans le domaine des systèmes de fichiers SSD pour Linux.
Aller plus loin
- Benchmark entre JFFS2, LogFS et UBIFS (291 clics)
- JFFS2 (90 clics)
- YAFFS (65 clics)
- LogFS (32 clics)
- UBIFS (184 clics)
# Bon article
Posté par analogue o/ (site web personnel) . Évalué à 10.
Merci pour cet article qui résume très bien la situation, ça permet d'y voir plus clair =)
[^] # Re: Bon article
Posté par ragoutoutou . Évalué à 10.
Le SSD est surtout intéressant pour le stockage à faible écriture ou les systèmes posant problème à la mécanique, comme les portables.
[^] # Re: Bon article
Posté par jmelyn . Évalué à 10.
La somme des temps de mouvement du bras disque dur et d'attente pour trouver le bon secteur sous la tête descendent rarement sous les 10ms. Ces retards deviennent prédominants en charge. Or les SSD annulent ces attentes: pas de mécanique en mouvement.
De plus, les débits de lecture augmentent de mois en mois. En voici un exemple (certes, encore un peu cher pour mon porte-monnaie): http://www.fusionio.com/iodrivedata.pdf . Pour mémoire, le débit d'un bon disque dur dépasse à peine 100MB/s.
Enfin, les tailles des SSD au format 2'1/2 sont en très forte progression: 32GB il y a un an, 320GB aujourd'hui et 1TB annoncé lors du CES de janvier dernier.
Malheureusement, dans ces temps troubles de grosses sociétés possédant des pouvoirs énormes, des nuages s'annoncent: Seagate semble prêt à faire un procès aux fabricants de SSD qui lui feraient de l'ombre: http://www.presence-pc.com/actualite/Seagate-28510/ . So, wait and see...
[^] # Re: Bon article
Posté par Julien . Évalué à 8.
Qu'en est-il ? Ces mécanismes vont-ils être supprimés avec l'apparition de FS appropriés ? Ces FS se limitent ils aux cas particuliers de l'embarqué où ces mécanismes sont absents ? Est-ce que l'augmentation de l'espace de stockage rend la création matériele de tels mécanismes plus compliqués ?
[^] # Re: Bon article
Posté par lfmarante . Évalué à 9.
Probablement, encore faudrait-il que microsoft veuille bien se bouger le cul. Y a qu'à voir tout les APN, Lecteurs mp3 etc tournant encore avec du FAT moisi...
[^] # Re: Bon article
Posté par Jean B . Évalué à 7.
A quand un système de fichier journalisé normalisé/lisible facilement par tous les OS ?
[^] # Re: Bon article
Posté par windu.2b . Évalué à 10.
Je vois bien un certain OS accepter sans rechigner d'implémenter (correctement et fidèlement) dans son noyau un FS librement documenté, normalisé, afin de faciliter les échanges de données avec les OS concurrents.
Non, là comme ça je ne vois aucune raison qui pousserait l'éditeur dudit OS à refuser de jouer la carte de l'intéropérabilité : c'est pas comme s'ils avaient déjà tout fait pour ne pas le faire, par le passé...
[^] # Re: Bon article
Posté par Jean B . Évalué à 6.
D'ailleurs il est amusant de constater que maintenant que ntfs-3g est stable WinFS va sortir (enfin du moins l'éditeur non-susnommé l'a annoncé et garanti qu'il sera meilleur que tous ses concurrents, un petit air de déjà vu tout de même (Piège dans le cyber espace tout ça..).
[^] # Re: Bon article
Posté par alexissoft . Évalué à 3.
[^] # Re: Bon article
Posté par Zakath (site web personnel) . Évalué à 10.
[^] # Re: Bon article
Posté par Philippe F (site web personnel) . Évalué à 4.
http://www.news.com/New-file-system-has-long-road-to-Windows(...)
[^] # Re: Bon article
Posté par pasBill pasGates . Évalué à 3.
Ca a d'ailleurs deja ete fait hein : http://www.fs-driver.org/
Bref, ca serait sympa que tu cherches un peu sur le sujet avant d'accuser MS de qqe chose...
[^] # Re: Bon article
Posté par windu.2b . Évalué à 10.
Tu verras alors que j'ai bien précisé que je ne croyais pas une seule seconde à l'implémentation par MS d'un FS autre que les leurs, dans leur noyau...
Parce que oui, je sais parfaitement qu'on peut rajouter des FS, en témoigne le driver sous XP (et sous Vista ?) permettant de lire (et d'écrire ? je sais plus trop, j'ai pas creusé la question) des partitions ext3 (reconnues cependant comme ext2, me semble-t-il).
Sauf que là, on parle d'un FS qui serait "standardisé" (pourquoi pas un FS existant, d'ailleurs ?) et destiné à remplacer la FAT vieillissante... Idéalement, il serait appréciable que chaque OS le propose nativement (ce qui rendrait donc les choses totalement transparentes pour l'utilisateur), et non devoir passer par une installation, toujours rebutante pour madame Michu.
[^] # Re: Bon article
Posté par psychoslave__ (site web personnel) . Évalué à 3.
* copie de fichiers avec des caractères accentués
* copie de fichiers de plus de 4Go (ISO de live-DVD par exemple)
C'est les deux seuls problèmes que m'ont posé ce système de fichier, et vous?
[^] # Re: Bon article
Posté par windu.2b . Évalué à 8.
[^] # Re: Bon article
Posté par Jean-Philippe (site web personnel) . Évalué à 10.
[^] # Re: Bon article
Posté par Ontologia (site web personnel) . Évalué à 5.
Pour l'efficacité, on repassera, mais ça suffit à convaincre pas mal de monde, surtout dans l'embarqué où la taille du code importe.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Bon article
Posté par abramov_MS . Évalué à 3.
[^] # Re: Bon article
Posté par David D (site web personnel) . Évalué à 2.
Pour un système de fichier (FS =file system) accessible pour tous les OS, il suffirait que MS décide de supporter les FS issus du libre (la doc n'est pas trop dur à trouver).
Ils pourraient aussi en dire plus de façon ouverte sur leurs FS à eux au lieu de forcer au reverse engineering, mais d'une certaine façon ça les forceraient un peu plus à être performant.
Ce que je trouve intéressant dans cet article, c'est plus d'indiquer des FS appropriés à la technologie utilisée, même s'ils perdent leur généricité (pour des performances accrues sur un disque dur, le système doit par exemple tenir compte des déplacements physiques des têtes de lecture/écriture ce qui n'est pas le cas sur de la mémoire flash).
[^] # Re: Bon article
Posté par ragoutoutou . Évalué à 7.
Ce que tu dis concernant la lecture, l'absence de parties mobiles, ... a déjà été dit et redit et je pense que personne ne le remet en cause.
[^] # Vitesse d'écriture
Posté par Kerro . Évalué à 8.
Il est possible que sur des machines qui sollicitent beaucoup les disques en écriture, la lenteur actuelle des SSD soit déjà compensée par le fait de ne pas dépenser 10 ms de positionnement des têtes.
Il semble que les SSD "normaux" actuels soient entre 25 et 80 Mo/s en écriture soutenue, et 0,5 ms de délai avant chaque écriture.
Un bon disque SAS 15.000 tours fait aux alentours de 95 Mo/s en lecture/écriture soutenue, et 5 ms de délai avant chaque écriture si on se limite aux premiers 20% de la surface du disque.
Exemple pour 1000 écritures de 1 Mo réparties sur 20% de la surface du disque:
SSD à 25 Mo/s: (1000 x 0.5 ms) + (1000 x 1 / 25) = 500 ms + 40 s = 40,5 s
SATA à 65 Mo/s: (1000 x 8ms) + (1000 x 1 / 65) = 8 s + 15,38 s = 23,38 s
SSD à 40 Mo/s: (1000 x 0.5 ms) + (1000 x 1 / 40) = 500 ms + 25 s = 25,5 s
SSD à 50 Mo/s: (1000 x 0.5 ms) + (1000 x 1 / 50) = 500 ms + 20 s = 20,5 s
SSD à 60 Mo/s: (1000 x 0.5 ms) + (1000 x 1 / 60) = 500 ms + 16,7 s = 17,2 s
SAS à 95 Mo/s: (1000 x 5 ms) + (1000 x 1 / 80) = 5 s + 10,5 s = 15,5 s
SSD à 80 Mo/s: (1000 x 0.5 ms) + (1000 x 1 / 80) = 500 ms + 12,5 s = 13 s
[^] # Re: Vitesse d'écriture
Posté par mosfet . Évalué à 7.
Cela fait plusieurs mois que je suis un forum sur lequel les geeks en puissance font des benchs avec leurs joujous et bien en raid je vois passer des 400 Mo/s et un disque seul atteint facilement les 100 Mo/s.
http://www.nokytech.net/forum/showthread.php?t=106705&pa(...)
J'envisage d'en acheter un des qu'ils sortent un 64 Go à moins de 1000 euros.
En fait il existe plusieurs technos et si tu suis tout le thread tu auras une vision concrète de ce qui existe et de leurs performances.
[^] # Re: Bon article
Posté par jmelyn . Évalué à 3.
De toute manière il suffit de suivre les valeurs mois après mois pour les voir s'envoler. Sans doute est-il encore un peu tôt pour jeter les disques durs à la poubelle, mais leurs jours semblent comptés.
Il faut encore attendre une baisse sensible des prix, une levée des incertitudes quant aux brevets éventuellement enfreints, et la montée en performance nettement au dessus de leurs équivalents mécaniques pour que les SSD deviennent une évidence pour tous. La seule inconnue reste: dans combien de temps. À mon avis, trois années suffiront.
[^] # Re: Bon article
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Bon article
Posté par Prosper . Évalué à 4.
L'articles est effectivement bien fourni en références. Pour les serveurs, une fois la fiabilité de ces "disques" prouvée, les SSD fourniront un impressionnant saut pour les vitesses d'accès. En effet, les serveurs hébergeant de multiples utilisateurs et ceux travaillant en virtualisation ont besoin d'accéder à de nombreux fichiers en même temps.
La somme des temps de mouvement du bras disque dur et d'attente pour trouver le bon secteur sous la tête descendent rarement sous les 10ms. Ces retards deviennent prédominants en charge. Or les SSD annulent ces attentes: pas de mécanique en mouvement.
Faudrait pas oublier que lorsque tu as ce genre d'architecture avec virtualisation et compagnie , tu utilises un SAN derrière ( en FC ou en iscsi , ca dépend du budget ... ) et tu travailles pas sur un seul disque mais des agregats du raid et cie , les débits sont loin de ceux d'un seul disque.
[^] # Re: Bon article
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Par contre, pour les latences, j'ai très très peur.
"La première sécurité est la liberté"
[^] # Re: Bon article
Posté par Prosper . Évalué à 4.
Ca dépend surtout de la distance entre ta baie et ton serveur , quand c'est de l ordre de la dizaine de metres sur du SAN Fibre Channel c est négligeable ( sur du iSCSI çà se voit deja plus ) , quand t'as des ISLs de plusieurs kilometres , là par contre ...
[^] # Re: Bon article
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
"La première sécurité est la liberté"
[^] # Re: Bon article
Posté par Olivier Serres . Évalué à 6.
[^] # Re: Bon article
Posté par pampryl . Évalué à 1.
Si tu veut comparer prix et capacité je te rejoins... mais prix et perfs... j'ai plus de doutes
surtout quand on parle de performances en écriture
Pour toi, un DD va plus vite en écriture qu'un SSD?
une cache en écriture, c'est sympa si
Comme sur un DD...
Il faut comme même faire le ratio entre le nombre de grosses écritures et celles de moindre taille qui tiennent dans le cache...
[^] # Re: Bon article
Posté par Jean-Max Reymond (site web personnel) . Évalué à 2.
www.storagesearch.com/easyco-flashperformance-art.pdf
[^] # Re: Bon article
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
J'avais en tête la taille de bloc de 64K pour avoir la vitesse max d'un disque dure mais vu l'article, il faut plus de 1Mo pour avoir cette vitesse.
Vu les différences de perfs entre SSD et disque dure, cela vaudrait le coup d'avoir un SSD juste pour tout ce qui est plus petit que 1Mo : les metadata et les petits fichiers, et un HD en parallèles pour les gros fichiers. On pourrait utiliser pleinement la bande passante des disques dure et la latence des SSD.
"La première sécurité est la liberté"
[^] # Re: Bon article
Posté par Richard Van Den Boom . Évalué à 2.
Les SSD utilisés ont des performances en écriture de l'ordre de 70-80Mo/s ce qui est très honorable et une fois en RAID5 donne des performances satisfaisantes.
Mais c'est surtout sur des applications demandant des latences faibles que ce genre de baies est intéressante, des volumes pour serveurs de fichier, mail ou web. Même pour certaines bases le gain est très important.
[^] # Re: Bon article
Posté par bubar🦥 (Mastodon) . Évalué à 5.
Ha si, que de manière naturelle, tout le monde emploi le terme 'article' et non 'dépêche' ;)
Merci encore
# excellent article
Posté par lolowan . Évalué à 10.
[^] # Re: excellent article
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à 10.
Ben quoi, faut aussi dire quand c'est bien :D
Alexandre COLLIGNON
[^] # Re: excellent article
Posté par Jakie Kasperwsky . Évalué à 5.
Candidat aussi au concours du lien qui permet de passer 15 minutes réellement productive au bureau !
[^] # Re: excellent article
Posté par Pierre Jarillon (site web personnel) . Évalué à 9.
Mon petit doigt me dit que Patrick est déjà en train de préparer un article sur le noyau Linux 2.6.25.
Je me régale d'avance (je triche un peu car j'ai déjà pu voir son texte). ;-)
Merci Patrick !
[^] # Re: excellent article
Posté par psychoslave__ (site web personnel) . Évalué à 4.
[^] # Re: excellent article
Posté par jihele . Évalué à 1.
(rqe : s/vont continuer à être utilisé/vont continuer à être utilisés/)
[^] # "Thread Patrick g"
Posté par Thomas Douillard . Évalué à 5.
# YAFFS sous Linux
Posté par eastwind☯ . Évalué à 5.
[^] # Re: YAFFS sous Linux
Posté par eastwind☯ . Évalué à 3.
[^] # Re: YAFFS sous Linux
Posté par GCN (site web personnel) . Évalué à 9.
Bientôt...
# terriblement efficace ?!
Posté par pipo_molo . Évalué à 7.
Hum, en pratique, c'est réalisable ? accéder directement à la flash d'un SSD connecté en SATA ou d'une carte SD connectée en USB ?
[^] # Re: terriblement efficace ?!
Posté par pipo_molo . Évalué à 2.
- block2mtd, apparament une émulation de mtd sut block device ... mais ne permettrait pas à priori de passer outre le contrôleur
- un patch http://marc.info/?t=116731222600007&r=1&w=2 à priori pour les CPU/SoC qui incluent une interface MMC, donc plutôt de l'embarqué.
Et l'auteur du patch en question dit: "the mtd layer doesn't deal with media larger than 4GB anyway at this point" dans un message d'avril 2007, donc c'est peut-être pas gagné pour les SSD et autres SDHC.
[^] # Re: terriblement efficace ?!
Posté par M . Évalué à 4.
Ca sert à rien vu que l'on passe encore par le controlleur de la sd qui émule la flash comme un disque.
Et l'auteur du patch en question dit: "the mtd layer doesn't deal with media larger than 4GB anyway at this point"
Et c'est toujours vrai.
# Diagramme
Posté par patrick_g (site web personnel) . Évalué à 8.
Bon pour ceux qui veulent l'original vous pouvez aller voir le onzième slide de ce document ppt : http://www.linux-mtd.infradead.org/doc/ubi.ppt
[^] # Re: Diagramme
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Tes articles sont denses, informatifs et faciles à lire. Que demander de plus à part une meilleure présentation ?
[^] # Re: Diagramme
Posté par patrick_g (site web personnel) . Évalué à 4.
[^] # Re: Diagramme
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Faire ta pub perso en faite.
"La première sécurité est la liberté"
[^] # Re: Diagramme
Posté par Pierre Jarillon (site web personnel) . Évalué à 8.
- rassembler de très bons textes perdus au milieu de tas d'autres
- avoir un historique en français de l'histoire de l'informatique au 21ème siècle
- avoir ta photo à côté ;-)
- te susciter des propositions d'évolution de carrière. Car si j'étais à la recherche de collaborateurs ce serait un argument de poids en ta faveur.
[^] # Re: Diagramme
Posté par patrick_g (site web personnel) . Évalué à 9.
N'exagérons rien ;-)
>>> avoir ta photo à côté
Plutôt mourir.
[^] # Re: Diagramme
Posté par viridis (site web personnel) . Évalué à -1.
http://a.wordpress.com/avatar/pvergain-128.jpg
[^] # Re: Diagramme
Posté par patrick_g (site web personnel) . Évalué à 5.
En revanche tu trouvera la réponse dans les commentaires de cette news puisqu'on avait pris des photos lors de la réunion modérorelecteurs : http://linuxfr.org/2007/06/29/22612.html
[^] # Re: Diagramme
Posté par viridis (site web personnel) . Évalué à 2.
Le point positif c'est que linuxfr ne pourra pas être tenu responsable de la divulgation d'info privée vu que c'est toi qui donne le lien ;)
Du coup, on va pouvoir finir notre vendredi bien pépère au fond de nos sièges.
[^] # Re: Diagramme
Posté par FreeB5D . Évalué à 4.
# augmentation du nombre de cycle d'écritures supportés ?
Posté par gc (site web personnel) . Évalué à 6.
[1] http://www.postgresql.org/docs/8.3/interactive/runtime-confi(...)
[^] # Re: augmentation du nombre de cycle d'écritures supportés ?
Posté par ragoutoutou . Évalué à 2.
Pour le moment, on va vers une baisse de la fiabilité, avec le développement des systèmes nand MLC (plusieurs couches par cellules) qui, pour des raisons de prix, est plus rentable au Go que le SLC (une couche par cellule).
Si on veut utiliser les SSD au mieux de leurs possibilités, il faudra de toutes façons avoir une approche plus intelligente que ce qu'on fait à l'heure actuelle avec les disques classiques. Sinon, la flash en général, à condition de pas trop souvent écrire dessus, c'est un support de stockage presque indestructible.
[^] # Re: augmentation du nombre de cycle d'écritures supportés ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
Pourquoi couches ? A cause de "layer" ?
C'est des bits. Une cellule flash ou eeprom, c'est un transistor avec une grosse grille. Les charges sont piégé derrière la grille comme pour la DRAM. Sauf que les courant de fuite doivent être infime et avoir une durée de vie supérieur à 64 ms des DRAM :) L'épaisseur d'oxyde est plus importante donc pour chargé, il faut augmenter les tensions (certaines puces Flash contiennent en interne les pompes de charges).
Comme pour les RAM, il y un ampli différentiel pour lire un bit. La différence de potentiel lu est faible quelques centaines de millivolt. Pour éviter les erreurs, il y a plein de bits ECC supplémentaires.
Les MLC utilisent le même principe que ces SLC mais au lieu de gérer 2 niveaux ("layer"...) de tension (0v - qq 100mv), ils gèrent 4 pour pour avoir 2 bits par cellule ou 8 pour 3 bits.
La densité est donc bien plus grande mais la sensibilité aux erreurs aussi.
"La première sécurité est la liberté"
[^] # Re: augmentation du nombre de cycle d'écritures supportés ?
Posté par steph1978 . Évalué à 7.
Je ne vois pas en quoi c'est se tordre l'esprit que de chercher à faire ça.
On le ferait sur un DD si il n'y avait pas de pb de temps d'accès.
Un algorithme de copy on write est toujours bon pour avoir de la journalisation et des snapshots.
Enfin, quel est le problème d'un flush avec ce genre d'algorithme ?
Bref, il est heureux que des gens se creusent la tête pour peut-être voir un jour se généraliser un FS qui soit plus efficace que FAT.
# Quelques questions.
Posté par Aldoo . Évalué à 10.
Alors sinon, quelques trucs que je n'ai pas trop compris : la gestion de l'usure se fait au niveau du contrôleur hardware, dans les SSD, non ? Qu'est-ce que la couche logicielle associée au système de fichiers apporte de plus ?
(En revanche, je vois très bien ce qu'on peut faire de moins : tous les algos de minimisation du déplacement du bras mécanique.)
Sinon, quelle différence entre un SSD (super cher : ~500€ pour 32Go), et une clé USB (moins chère : ~150€ pour la même capacité), à part l'interface (or je sais que la conversion SATA/USB ne coûte quasiment rien) ?
Techniquement, le SSD a un taux de transfert qui peut atteindre environ le triple de celui des meilleures clés USB, mais pourquoi ? (le débit d'USB2 étant pourtant bien supérieur à celui des meilleures clés)
# Unités ?
Posté par Kerro . Évalué à 1.
Bien sûr on peut se reporter à la documentation d'iozone pour deviner, mais ce n'est pas très... pro.
Exemple sans unités:
J'ai testé avant-hier un vieux disque-dur sur une vieille carte-mère HP (honte à moi, du HP...). Il faisait 4,1
On est bien avancé sans l'unité qui va avec :-)
4,1 ms de piste à piste ?
Non non, 4,1 Mo/s de transfert.
Poubelle.
[^] # Re: Unités ?
Posté par patrick_g (site web personnel) . Évalué à 6.
The raw numbers are in KByte/sec. The relative numbers denote magnitude of UBIFS relative to another FS.
[^] # Re: Unités ?
Posté par Kerro . Évalué à 3.
Comment ça j'ai lu trop vite ? Pas du tout, pas du tout. J'ai des preuves. Plein !
# Pertinence de cette dépêche ?
Posté par AiZ . Évalué à 5.
Tous ces systèmes de fichiers ne sont-ils pas dédiés dans leur grande majorité aux MTD et par-là même inutilisables sur des block devices tels que les SSD et autres clés USB ?
Merci d'éclairer ma lanterne,
AiZ
[^] # Re: Pertinence de cette dépêche ?
Posté par patrick_g (site web personnel) . Évalué à 4.
[^] # Re: Pertinence de cette dépêche ?
Posté par steph1978 . Évalué à 3.
En fait, je partage son interrogation.
Si un SSD est vu comme un disque dur classic et que c'est le contrôleur qui fait le travail, quel sera l'usage de ces FS sur un SSD ?
à moins qu'un SSD soit vu à la fois comme un /dev/sdx et un /dev/mtdx ?
steph
[^] # Re: Pertinence de cette dépêche ?
Posté par TeXitoi (site web personnel) . Évalué à 3.
Donc, oui, pour les SSD actuels, ça sert à rien, c'est quand on accède directement à la flash que c'est utile.
# Complément...
Posté par M . Évalué à 10.
Déja avant de parler des systèmes de fichiers flash, MTD à ses limites :
- pas de support des flashs de plus de 4Go
- pas de support de contrôleur avec dma (en tout cas pas de manière simple)
Ce algorithme est implémenté par les constructeurs de disques SSD dans des microcontrôleurs faisant le lien entre la mémoire flash et l'interface sata. C'est certes transparent pour l'utilisateur mais cela signifie que les systèmes de fichiers traditionnels, avec toutes leurs limitations et tout leur code complexe dédié à la minimisation des temps d'accès par le bras de lecture, vont continuer à être utilisé.
C'est surtout que l'on ne sait pas trop ce qu'il fait et s'il est vraiment robuste. De plus ces algorithmes pour être efficace doivent être optimisé pour certains patterns et donc certains filesystem.
Néanmoins ces disques SSD à base de mémoire flash sont affligés d'un défaut important puisqu'ils ne supportent qu'un nombre restreint de cycles d'écritures (typiquement de l'ordre de 100000).
C'est pire que ça. Là tu parles de la NOR.
Mais c'est de la NAND, où les blocks où l'on écrit les données ne sont pas garanti (sauf le premier). Donc ils peuvent être mauvais en sortie d'usine ou au cours du temps.
Il est donc nécessaire d'utiliser des algos de corrections d'erreur "ecc" pour récupérer les données si le block "fatigue". Il faut aussi être capable de déplacer les données d'un secteur fatigué et de le marqué comme mauvais s'il ne marche plus.
Le gros problème de JFFS2 est qu'il a besoin d'examiner tous les blocs mémoires au moment du montage du système de fichiers afin de construire l'index qui est conservé en RAM.
Il y a le mode sumary qui permet de ne pas examiner tous les blocs mémoires au moment du montage du système. Un résumé est stocké à la fin de chaque "block".
De plus YAFFS fait la même chose (sauf s'il est éteint proprement dans quel cas il sauve un son état en flash).
Un autre problème de jffs2 c'est qu'il est très gourmand en RAM.
YAFFS [...] Ce système a été conçu spécifiquement pour la mémoire flash NAND et il est donc a priori bien adapté aux disques SSD.
Il a les même problème que jffs2 : temps de montage et conso RAM linéaire par rapport a la taille de la flash (la pente est seulement plus faible). Donc non il est pas très adapté au gros média.
De plus ce fs ne gère pas bien la NAND et notamment les bit flips sur les lectures.
PS : les slides présentant yaffs2 et ses évolutions futures sont dispo quelque part sur le net.
LogFS
Il ne gère pas vraiement les NAND pour le moment : http://marc.info/?l=linux-kernel&m=120702790910653&w(...)
UBI et UBIFS
Comme cette couche UBI est déjà présente dans le noyau il parait éminemment logique de construire un système de fichiers gérant les disques SSD par dessus cette infrastructure afin de profiter de ses avantages et de factoriser le code noyau
Plus précisément, pour diviser les difficultés celui qui voulait faire jffs3 a développé UBI d'abord, puis UBIFS.
Comme tu le soulignes UBI+UBIFS est très gros. Sera t il simple d'embarquer un support partiel (lecture seul) dans les bootloader ?
Sera t il simple de le garantir sans bug (ou au moins de l'auditer).
Pour le moment on a pas de benchmark très complet (petite flash/très grosse flash). http://osl.sed.hu/wiki/ubifs/index.php/Mount_results montre des résultats pas terrible.
Un autre avantage est qu'UBIFS utilise un cache pour les données (writeback) ce qui permet d'éviter d'écrire les données de façon strictement synchrone.
Est-ce un résultat souhaitable sur des périphérique embarqué qui peuvent être éteint n'importe quand ?
De plus tous ces file systèmes sont inadapté dans le cas de disque (ou périphérique) externe : on voudrait par exemple les monter en mass storage partout, ce qui implique l'émulation disque dur et du FAT... Et du coup on est obligé de passé par des flash translation layer qui émule un disque dur sur la flash. C'est ce que l'on trouve dans les SD, clef usb et SDD.
En conclusion pour les SDD il faudra que les fabriquant propose une interface qui permette de desactiver la FTL. Mais cela pose des problèmes.
D'abord ça oblige à creer un nouveau protocole de communication avec ces disques.
De plus ces disques ne seront plus bootable par les bios à moins d'écrire en flash le même format que celui qu'utilise le microcontrôleur du disque...
Enfin les différents constructeurs n'embarque pas forcement le même type de flash et elle ne sont pas cascadé de la même manière, ... Actuellement c'est masqué par la FTL.
Il faudra aussi que des filesystemes flash fasse leur preuve sur les gros média et que MTD soit améliorer.
[^] # Re: Complément...
Posté par M . Évalué à 10.
J'oubliais : tu parlais d'optimisation des fs classique par rapport à la tête de lecture. Mais là aussi il faut optimiser le fs suivant l'organisation des différentes flash qui compose le disque (oui il y en a rarement qu'une seule).
Et effet on peut voir ca comme un RAID-0 et pour masquer la latence d'accès à la flash il faut bien repartir les écritures sur les différentes flashs.
[^] # Re: Complément...
Posté par patrick_g (site web personnel) . Évalué à 10.
[^] # Re: Complément...
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
[^] # Re: Complément...
Posté par phentex . Évalué à 2.
De plus tous ces file systèmes sont inadapté dans le cas de disque (ou périphérique) externe : on voudrait par exemple les monter en mass storage partout, ce qui implique l'émulation disque dur et du FAT... Et du coup on est obligé de passé par des flash translation layer qui émule un disque dur sur la flash. C'est ce que l'on trouve dans les SD, clef usb et SDD.
Et ben comme ça ce sera l'occasion de faire le ménage et de virer pour de nécessité de compatibilité avec FAT...
# Et à plus long terme ?
Posté par gayet . Évalué à 4.
Est-ce que l'OS va devoir considérer les "mémoires non volatiles" comme des Swap? Dans ce cas toutes les applications seront lancées une fois pour toutes puis stockées comme des images RAM, directement utilisable (à l'image d'une application Palm).
Il y a sûrement des obstacles techniques aujourd'hui mais est-ce la direction que suivent les OS à long terme ?
[^] # Re: Et à plus long terme ?
Posté par illogict . Évalué à 1.
Malheureusement, la capacité actuelle n'est que de 512ko, mais ça ne peut que s'améliorer :)
[^] # Re: Et à plus long terme ?
Posté par Jeanuel (site web personnel) . Évalué à 2.
"640K ought to be enough for anybody." On y est presque.
[^] # Re: Et à plus long terme ?
Posté par M . Évalué à 2.
Ca peut se traduire par :
- une convervation plus longtemps en cache mémoire avant de flusher les donnée sur le disque
- désactiver l'option du fs qui stocker le temps du dernier accès
- monter les fs temporaire en RAM (/tmp, /var/tmp, ...)
[^] # Re: Et à plus long terme ?
Posté par reno . Évalué à 3.
Pas avec cette techno:
- les temps latences pour l'écriture ou la lecture dans une Flash s'ils sont bien inférieurs à ceux d'un disque restent très supérieur à ceux d'une RAM.
- les temps de latences devraient *augmenter* un peu avec les Flash MLC qui fournissent des capacités supérieures, pas baisser.
Je ne connais pas les chiffres exacts, mais je dirais au pif environ 10^-4s pour la Flash contre 10^-7s pour la RAM, un facteur mille ce n'est pas rien..
Donc je pense que l'organisation actuelle de nos application va rester..
# 140 years @ 50GB write per day
Posté par krumtrash . Évalué à 4.
http://www.mtron.net/English/Product/ProductDetail.asp?itemc(...)
[^] # Re: 140 years @ 50GB write per day
Posté par nonas . Évalué à 10.
Quand on t'annonce 140 ans @ 50 Go par jour alors que plus bas tu as un MTBF de 1 million d'heure (soit environ 114 ans) tu peux déjà te poser des questions.
Ensuite tu vois la présence des données qui n'est "garantie" que pour 10 ans et après que le produit n'est garantie que 3 ans...
[^] # Re: 140 years @ 50GB write per day
Posté par M . Évalué à 6.
En effet avec 10^6 cycles d'écriture possible, sur un disque de 2Go, ça donne 2*10^6Go au total, soit pour une écriture journalière de 50Go, plus de (2*10^6Go/50Go ~ 140*265 ) jours, soit 140 ans.
[^] # Re: 140 years @ 50GB write per day
Posté par jihele . Évalué à 10.
# Un raz de marée ? J'achète !
Posté par alnicodon . Évalué à 3.
Mais y a pas grand chose de vendu au grand public, où je me trompe ?
Sur les sites de vente français, sorti des Transcend (débits plutôt limites, si j'ai bien suivi), il reste quoi ? Un Samsung par-ci (zut, uniquement SATA ! Et pour maintenir mon vieux portable resté en bon vieux "PATA"?), un super talent par là (ah, ben non, pas en France)
Pourtant, y a des super trucs, je ne citerai en plus de Intel que Pny (http://www2.pny.com/MarketingPromotions/SolidStateDrives/2_5(...) ), mais... pas distribué, en tout cas ne m'est pas accessible.
Al., qui les a un peu là
[^] # Re: Un raz de marée ? J'achète !
Posté par Jean B . Évalué à 2.
Il y a des adaptateurs SATA/PATA.
Et en effet il y a peu de modèle vendu au grand public, mais c'est normal il y a encore très peu de constructeurs et de modèles. D'ici un an ça devrait être viable.
# Serveur faible énergie ?
Posté par jihele . Évalué à 3.
Quelque chose qui permettre de faire un peu de FTP, héberger des sites web (php, sql), quelques comptes mail, décentraliser, quoi, mais sans que chacun doive laisser un PC entier tourner perpétuellement chez lui. Le problème énergétique doit être un frein à l'autohébergement pour pas mal d'entre nous.
Cela dit ça existe peut-être déjà des petites architectures qui consomment peu. Mais là je pense à un truc sans écran, pilotable via un acces distant (un autre PC du réseau). Vraiment réduit.
(Et cela dit à quoi bon réduire la conso d'un serveur s'il est relié à une freebox/radiateur ?)
[^] # Re: Serveur faible énergie ?
Posté par patrick_g (site web personnel) . Évalué à 5.
http://www.soekris.com/
[^] # Re: Serveur faible énergie ?
Posté par jihele . Évalué à 1.
Il faudrait voir comment ça se comporte niveau conso et perfs. Mais ça semble répondre précisément au "besoin" dont je parlais.
[^] # Re: Serveur faible énergie ?
Posté par jihele . Évalué à 3.
[^] # Re: Serveur faible énergie ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
[^] # Re: Serveur faible énergie ?
Posté par jihele . Évalué à 2.
Le prix des deux est comparable. Soekris en boîte 250 €, FAT PC $300.
[^] # Re: Serveur faible énergie ?
Posté par TeXitoi (site web personnel) . Évalué à 3.
Dire que l'alim d'une soekris est de 20W veux dire que si la machine consome plus de 20W, ca marchera plus. Ca veux pas dire que ca consomme 20W en continue.
A mon avis, le FIT PC et la soekris consomment autant l'un que l'autre : en effet, c'est exactement les mêmes composants énergivore : un Geode à 500MHz (pour la soekris 5501-70).
Pour info, ma via PD6000E à 600MHz avec une alim 60W, carte wifi ralink et disque dur 3.5 160Go consomme 20W (de tête, mesuré avec un wattmètre).
Perso, le fic pc m'a l'air très interessant, mais il lui manque la possibilité de faire point d'accès wifi, ce que permet la soekris, mais la soekris n'a ni le port vga, ni la sortie audio.
[^] # Re: Serveur faible énergie ?
Posté par jihele . Évalué à 2.
Si c'est pour faire un server, le VGA et la sortie audio m'importent peu. Mais le wifi aussi, en fait.
Une chose à laquelle je n'ai pas pensé, en terme de perf, c'est l'upload. En ADSL, c'est peut-être limitant. Evidemment ça dépend de la charge du serveur.
RIen à voir, mais les boîtes des soekris sont super jolies. Les fit pc sont pas mal non plus, mais moins chouettes à mon avis.
Je devrais mesurer la conso de mon PC, elle est peut-être beaucoup plus faible que je ne l'imagine. Cela dit les boîtiers dont on parle ont aussi l'avantage de ne pas faire de bruit.
[^] # Re: Serveur faible énergie ?
Posté par TeXitoi (site web personnel) . Évalué à 3.
Il n'y a en général pas plus que nominal < max.
Si c'est pour faire un server, le VGA et la sortie audio m'importent peu. Mais le wifi aussi, en fait.
En fait, l'utilité que j'en ai personnellement, c'est un serveur routeur. Comme dans serveur, il y a serveur mpd, la sortie audio est importante. Le VGA ne l'est pas, c'est juste une facilité. Mais bon, chacun a ses besoins spécifique ;-)
Une chose à laquelle je n'ai pas pensé, en terme de perf, c'est l'upload. En ADSL, c'est peut-être limitant.
Il me semble qu'une soekris 4800 est suffisante pour chiffrer le débit de l'upload ADSL, donc pas de problèmes avec les geodes à 500MHz. Sur http://www.kd85.com/ y'a le bench de ssl.
Je devrais mesurer la conso de mon PC, elle est peut-être beaucoup plus faible que je ne l'imagine.
Mon sempron 2800 avec une carte nvidia intégré (d'il y a 3-4 ans) et un écran TFT 15" consomment en tout 120W (dont 15W du moniteur je pense). Je crois que l'alim est une 200W (barebone).
[^] # Re: Serveur faible énergie ?
Posté par jihele . Évalué à 4.
Je ne comprends pas. Tu veux dire qu'il n'y a pas de généralité ? Qu'on a toujours max > nom mais qu'il n'existe pas de N tel qu'on ait toujours en général et par sécurité max > N x nom ?
Il me semble qu'une soekris 4800 est suffisante pour chiffrer le débit de l'upload ADSL
Je voulais dire que pour installer un serveur chez soi il ne suffit pas que la machine tienne la charge, il faut aussi avoir une connexion perso suffisante en UL pour que ça rame pas trop du point de vue de l'utilisateur.
Mon sempron 2800 avec une carte nvidia intégré (d'il y a 3-4 ans) et un écran TFT 15" consomment en tout 120W
Ca fait déjà pas mal plus. En admettant qu'on n'utilise pas d'écran on est quand même dans un ordre de grandeur de 100 Watts. Soit vingt fois plus.
[^] # Re: Serveur faible énergie ?
Posté par TeXitoi (site web personnel) . Évalué à 4.
Oui, c'est ce que je veux dire. En fait, en conception, il faut que les pics de consomations soient inférieurs au max, et c'est tout. En pratique, je n'ai constaté aucun lien, d'autant plus que, souvent, les alims prennent une marge de sécu en proportion avec l'évolutivité du produit (possibilité d'ajouter des composant energievore).
Je voulais dire que pour installer un serveur chez soi il ne suffit pas que la machine tienne la charge, il faut aussi avoir une connexion perso suffisante en UL pour que ça rame pas trop du point de vue de l'utilisateur.
OK, OTAN pour moi.
Soit vingt fois plus.
Oui, d'ou l'interret de ces petites boites pour du serveur.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.