vendredi 10 octobre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Les systèmes de fichiers pour disques SSD

Posté par patrick_g (page perso, ). Modéré le 04 avril 2008.
2
Depuis plusieurs mois les disques durs basés sur de la mémoire flash, aussi nommés disques SSD, commencent à apparaître dans des machines comme l'EeePC d'Asus ou le MacBook Air d'Apple. De plus il est possible d'acheter ces disques séparément pour les installer dans des ordinateurs de bureau afin d'augmenter leurs performances.
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.

> Lire la suite (96 commentaires, moyenne: 5,1).   [dépêche : 15638 caractères]

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.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Bon article

Posté par analogue o/ (page perso, ) le 04/04/2008 à 10:13. (lien). Évalué à 10.

La technologie SSD représente définitivement l'avenir du stockage, et cet avenir est relativement proche dans le monde des serveur.

Merci pour cet article qui résume très bien la situation, ça permet d'y voir plus clair =)

--
Votez contre le cinéma sur DLFP: http://linuxfr.org/tracker/296.html
Le lien pour voter est en haut à droite.

excellent article

Posté par lolowan () le 04/04/2008 à 10:19. (lien). Évalué à 10.

franchement, cette dépêche est un bon candidat à l'article du mois. bon je sais on n'est que le 4 avril ...

YAFFS sous Linux

Posté par eastwind (Jabber id, ) le 04/04/2008 à 10:22. (lien). Évalué à 5.

La GP2X utilise la YAFFS pour son système Linux le firmware est libre , necessite un peu d'amélioration niveau temps de boot , mais sinon je trouve très correcte pour les accès à la carte SD . Ensuite la vitesse d'accès dépend aussi de la carte elle même . (je ne suis pas un fin connaisseur mais je suppose que les cartes estampillé classe 6 , turbo , et 150 X on un accès plus rapide que les autres ... )

terriblement efficace ?!

Posté par pipo_molo () le 04/04/2008 à 10:43. (lien). Évalué à 7.

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.

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 ?

Diagramme

Posté par patrick_g (page perso, ) le 04/04/2008 à 10:54. (lien). Évalué à 8.

Haaa....mon fabuleux diagramme en ascii art est tout cassé !

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

augmentation du nombre de cycle d'écritures supportés ?

Posté par gc (page perso, ) le 04/04/2008 à 11:05. (lien). Évalué à 6.

Au lieu de se tordre l'esprit à faire un système de fichier minimisant les écritures, ce qui de toutes façons sera probablement une arlésienne pour la majorité des utilisations serveur (par exemple, par défaut PostgreSQL demande à l'OS de flusher toutes les écritures sur disque, pour minimiser les risques en cas de crash de la machine[1]), n'y a-t-il pas des perspectives d'augmentation du nombre de cycle d'écritures supportées par le hardware, potentiellement moyennant une augmentation raisonnable du prix ? Après tout, on n'en est qu'aux débuts de l'utilisation de cette technologie pour stocker des informations système et données "pérennes" (encore que ce soit un grand mot pour les disques durs, mais enfin, c'est plus pérenne que l'utilisation supposée d'origine des mémoires flash, un support de transport de données ou de stockage pour des périphériques dédiés comme des APN ou des baladeurs), l'utilisation d'une technologie peut couramment influer sur son évolution.

[1] http://www.postgresql.org/docs/8.3/interactive/runtime-confi(...)

Quelques questions.

Posté par Aldoo (Jabber id, ) le 04/04/2008 à 11:21. (lien). Évalué à 10.

Déjà bravo pour cet article.

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 () le 04/04/2008 à 13:34. (lien). Évalué à 1.

Il manque "juste" les unités dans les résultats des benchs.

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.

Pertinence de cette dépêche ?

Posté par AiZ () le 04/04/2008 à 15:40. (lien). Évalué à 5.

Bonjour,

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

Complément...

Posté par Matthieu C () le 04/04/2008 à 21:11. (lien). Évalué à 10.

Un petit complément un peu plus orienté sur l'utilisation dans le domaine des flashs dans l'embarqué.

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.

Et à plus long terme ?

Posté par gayet () le 06/04/2008 à 09:28. (lien). Évalué à 4.

Je n'y connait rien sur le plan technique mais est-ce que ce n'est pas l'organisation complète de nos applications qui devra être revue ?

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 ?

140 years @ 50GB write per day

Posté par krumtrash () le 06/04/2008 à 17:32. (lien). Évalué à 4.

Est-ce que les algos pour minimiser l'impact de l'écriture sur SSD est nécessaire alors que certain produit propose une endurance de 50Go d'écriture séquentiel par jour pendant 140 an ?

http://www.mtron.net/English/Product/ProductDetail.asp?itemc(...)

Un raz de marée ? J'achète !

Posté par alnicodon () le 07/04/2008 à 23:53. (lien). Évalué à 3.

Ouais j'achète.

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à

Serveur faible énergie ?

Posté par jihele () le 08/04/2008 à 14:27. (lien). Évalué à 3.

Selon le gain au plan énergétique, je me demande si en couplant ça à un micro genre ARM, on pourrait pas faire des petits serveurs très légers.

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 ?)