Sébastien Koechlin a écrit 849 commentaires

Imaginons un RAID sur 3 disques, ta solution est de faire un strip de 4 Ko, soit 2Ko sur le premier disque, 2 Ko sur le second disque, et les 2 Ko suivant servant de CRC.

Je vois trois inconvénients:

1. Cela est propre au RAID-5: Comme expliqué par Kerro, toutes les têtes de lectures doivent être synchronisées sur le même strip. Le temps d'accès n'est pas amélioré par le nombre de disques contrairement au RAID-1.

2. Les secteurs sur disque font 512 octets, et c'est le seul niveau d'atomicité connu des disques. Les FS manipulent généralement les méta-données par secteur et non par page mémoire, donc ton optimisation ne fonctionnera pas sur les méta-données. Idem pour les journaux à cause de l'atomicité.

3. Pour amélioré les I/O, en ATA on fait des opérations sur plusieurs blocs d'un coup. Les disques permettent généralement de lire 16 secteurs disque d'un coup (8Ko), ce qui permet d'anticiper les demandes (généralement lorsqu'on demande un secteur, on risque de demander le suivant). Avec ton strip de 4Ko, il y a un bloc de 2Ko de CRC pour 4 Ko de données; j'ai peur que rien dans la chaine OS/Controleur/Disque ne soit capable de fusionner les requêtes à cause du trou de 2 Ko; ce qui entrainerait une baisse des performances en lecture.

Je ne comprends pas à quoi se rapporte cette remarque.

Ca se rapporte au fait que les gens choisissent généralement du RAID-5 pour économiser quelques euros; rien à voir avec toi.

Je ne suis pas d'accord.

Je n'ai pas comparé le RAID 1 au RAID 0, mais à un disque seul:
- le RAID 0 n'est pas du RAID à mes yeux, il n'y a pas de redondance.
- on compare le gain de sécurité et l'impact sur les performances lorsqu'on fait de la redondance par rapport à la solution sans redondance

RAID-5:

En lecture tu pars de l'hypothèse qu'il n'y a que 3 disques; donc les lectures sont réparties sur 2 disques; c'est bien ce que j'ai dis, et ce n'est plus vrai s'il y a plus de 3 disques.

En écriture les performances ne sont pas 50% moins rapide (50% moins rapide = 2 fois plus rapide). Pour toute écriture il est nécessaire de faire deux lecteurs et deux écritures; c'est dont un surcout de 300% (4 fois moins rapide) en ignorant le temps de calcul du CRC. Pour les zones souvent utilisées il y a le cache mémoire qui évite heureusement de faire les lectures; mais sur les données volumineuses comme une bonne base de données ou des fichiers vidéos, c'est très pénalisant. Si le système de fichier est journalisé sur les données en prime, c'est encore +400% d'opérations sur le disque par rapport à l'écriture initiale. N'oublions pas la mise à jour des méta-données (on double encore les IO). (Vous êtes toujours content d'avoir économisé 70 euros ?).

Concernant les vérifications des matrices; ce n'est effectivement pas fait à la lecture; mais il est possible de les vérifier (commande /usr/share/mdadm/checkarray sous debian) sans interrompre le système. De plus en plus de distributions proposent d'automatiser ce test dans la crontab toutes les semaines ou tous les mois.

Je me réponds à moi-même, après consultation des sources (toujours lire les sources).

Il y a bien un algo de répartition des lectures sur les deux disques.

Il mémorise la position de la dernière lecture; et envoi la requête vers le disque qui est le plus proche.

L'inconvénient de cette méthode, c'est que si on a plusieurs matrices RAID, la tête de lecture ne va pas forcément rester près du dernier bloc lu.

Bonne idée d'aborder les performances.

En RAID1:

En lectures: elles sont normalement distribuées sur les deux disques; en théorie le débit devrait être doublé. D'après http://kernelnewbies.org/KernelProjects/Raid1ReadBalancing ce n'est pas fait sous Linux, donc la lecture actuelle offre les performances d'un disque.

En écriture, il faut écrire les données sur les deux disques; donc transférer deux fois les données au(x) contrôleur(s) disque. Tout n'est pas forcément parallélisable, cela dépends du chemin des données; on a donc un petit surcout à l'écriture par rapport à un disque

En RAID5:

En lectures: les lectures sont globalement distribuées sur N-1 disques, donc le débit est augmenté d'autant.

En écriture: L'écriture est complexe: pour écrire un bloc, il faut lire l'ancien bloc de données, écrire le nouveau bloc de données, lire l'ancien bloc de CRC, recalculer le CRC, et écrire le nouveau CRC. Dans le cas où l'on ré-écrit tous les blocs dans le même groupe, on peut calculer le nouveau CRC sans relire l'ancien. Il y a encore d'autres optimisation sur écritures multiples pour réduire les lectures; mais le coût d'une écriture est grosse; nécessite de la mémoire et du temps de calcul.
Pour écrire une donnée, il faut lire deux blocs et en écrire deux.

C'est cette complexité, et les risques de problèmes entre les différentes étapes qui rendent le RAID-5 si fragile.

Si ton site est un site web qui tourne sous Apache, il existe un module qui fait cela très bien, c'est mod_include http://httpd.apache.org/docs/2.2/mod/mod_include.html
Il vient par défaut depuis des lustres, il est beaucoup plus léger que PHP et bien documenté.

Si tu veux pré-générer les pages; cpp est le préprocesseur C, il est également facile a utiliser et très largement distribué sur de très nombreuses plateformes.

Pour remettre ta matrice, tu peux tenter de ré-introduire la partition défectueuse:

mdadm /dev/md3 --add /dev/sda2

Mais je te conseille fortement de regarder quelle est la cause de la perte de la partition; regarde dans les logs du système, dmesg, et regarde ce que dit smartctl (regarde en particulier Reallocated_Sector_Ct, Current_Pending_Sector...)

Le fait que les autres partitions fonctionnent toujours montrent simplement qu'il n'y a pas eu d'erreurs dessus; mais si le disque est en train de lacher, ça ne va peut-être pas tarder.

Si tu changes le disque; même principe, tu n'as qu'a ré-introduire les nouvelles partitions avec mdadm --add.

Encore un détail: tes deux disques ont exactement la même géométrie; est-ce que se sont exactement les mêmes modèles, venant de la même série et du même carton ? Depuis quelques années maintenant, la bonne pratique est de mélanger les disques; parce que les modèles identiques ont tendance à avoir des durées de vie identiques, et que dans le RAID, le plus important est que tous les disques ne tombent pas en panne en même temps.

Dans les logs, tu peux tracer les temps de service des requêtes; si tes requêtes prennent plusieurs secondes; il y a un risque d'avalanche comme tu le décris.

mod_status donne pas mal d'information aussi sur le parallélisme des requêtes et sur le temps de traitement.

Je te conseille de consulter Madame Irma; parce que vu les informations que tu donnes, il n'y a qu'avec une boule de cristal que l'on peut t'aider.

"Pourquoi ? T'as des sources ? Je ne vois pas de différence théorique entre les deux ..."

Oui, j'ai des sources, dans /usr/src/linux//Documentation/md.txt

Degraded = il manque un disque
Dirty = arrêt brutal
Le cas classique c'est la coupure de courant avec la défaillance d'un disque (l'un entrainant l'autre).

"If a raid5 or raid6 array is both dirty and degraded, it could have
undetectable data corruption. This is because the fact that it is
'dirty' means that the parity cannot be trusted, and the fact that it
is degraded means that some datablocks are missing and cannot reliably
be reconstructed (due to no parity).

For this reason, md will normally refuse to start such an array. This
requires the sysadmin to take action to explicitly start the array
despite possible corruption."

Je viens de passer chez LogiPro, (le spécialiste à Paris des solutions professionnels sous Atari, Amiga et PC); pour regarder la boite de la dernière version de windows, la version 3.1 (en attendant la version workgroup annoncée prochainement).

La boite précise bien que les 6 disquettes sont sensibles à la chaleur et aux champs magnétiques.

J'ai deux questions:

- Est-ce que tu pourrais faire une capture d'écran du bling bling ?
- Est-ce que ça tourne avec les drivers libres des cartes ATI ? Ou bien uniquement avec les drivers proprios ?

"le RAID 5 étant, à mon avis, trop dangereux à cause de son taux de panne"

C'est même pire que cela; le RAID-5 logiciel n'a pratiquement aucun avantage. La perte d'un disque risque de faire perdre toute la matrice contrairement au RAID-5 matériel.

"Si à la place on prend une carte RAID, ça coûte environ 100 € (les cartes à 36 €, je ne suis pas certain qu'elles soient "matériel")."

Même à 100€, je ne connais pas de carte RAID matériel; les premiers prix tournent autour de 300€, et pour ce prix, on a rarement la batterie de secours qui permet de faire du RAID-5.

Ton BIOS ne gère pas réellement le RAID, a priori, il ne fait que deux choses:

- Il renseigne l'OS sur la configuration des disques à utiliser; afin que l'OS puisse faire du RAID logiciel avec les bon paramètres.

- Il permet à la ROM x86 mode-réel de la carte contrôleur disque de booter la machine directement sur le RAID.

Pour tout le reste, c'est un pilote logiciel qui fait le travail.

De ce que j'ai lu, c'est complètement invisible. Dans le cas contraire, même les utilisateurs de windows auraient du mal à installer l'OS.

Par contre, le matériel branché dessus risque d'être récent, et il est possible que certaines choses soient mal ou pas supportées (controleurs secondaires pseudo-raid Sata par exemple) mais c'est plus une question d'age que de bus.

Ca dépends beaucoup de l'age et de la technologie de ton écran.

Les écrans modernes sont protégés contre les fréquences trop élevées. Ils affichent souvent un message "hors fréquence" via l'OSD si la carte envoi une synchro trop rapide. Ces écrans transmettent également leurs capacités via le protocole DDC (voir wikipedia) à l'ordinateur (sous réserve du support par l'écran, par le cable et par la carte vidéo).

Les veux écran CRT des années 1990 sans protection étaient effectivement capable de claquer si on envoyait une fréquence trop élevée pendant trop longtemps (il fallait supporter avant ça une ou plusieurs minutes d'images brouillées et de bruits désagréables).

Si ton écran est suffisamment récent, et que DDC fonctionne (voir les logs du serveur X), c'est peut-être un vieillissement un peu rapide de l'écran qui ne supporte plus la fréquence max annoncée.

Est-ce que les deux écrans sont de la même série ?

Je confirme, les chipsets vidéos intel intégrés sont suffisamment puissants pour faire un bureau 3D, pour jouer à TuxRacer et si tu souhaites utiliser ton portable sur batterie, tu gagneras en autonomie et en température.

J'imagine que tu es l'auteur de cette page ?

"Sur les systèmes de fichiers journalisés (ext3, reiserfs), il existe un attribut sur le fichier qui correspond au dernier accès en lecture."

Cela n'a rien à voir avec les systèmes de fichier journalisés; c'est POSIX qui demande la présence de la date de dernier accès; et historiquement c'est le cas sous Unix depuis fort longtemps. ext2 par exemple, possède cet attribut.

Voir par exemple http://fr.wikipedia.org/wiki/Inode

Ton calcul m'a l'air un peu faussé.

Tu veux quelque chose de plus petit; effectivement, le k45 est petit.

Par contre, tu parles de diminuer la consommation; et là, je ne suis pas certain que tu choisisses la bonne solution. Certe, l'alim du k45 est étiqueté 100 Watts, mais ça ne veut pas dire qu'elle consomme 100 Watts en permanence, c'est sa capacité maximale.

Pour réduire la consommation, on peut agir sur plusieurs axes:

- Changer le disque dur, en particulier passer à un modèle 2,5 pouces, avec un adaptateur à quelques euros, on peut le brancher sur une machine ordinaire. Il existe également des disques 3,5 pouces basse consommation.

- Choisir une alimentation avec un haut rendement, ainsi moins d'énergie est dissipée en chaleur.

- Choisir un CPU moderne. Ton serveur ne consomme probablement pas beaucoup de CPU, donc à nouveau ce n'est pas la puissance crête qui compte le plus; mais la capacité à réduire la consommation. Les dernières générations sont capables de baisser grandement les besoins énergétique en veille. Les CPU de portables sont également très économiques; mais difficile à trouver.

- Mettre les mains dans le kernel pour activer les modes d'économie d'énergie: kernel tickless, réduction de la fréquence, mode ACPI d'économie d'énergie. Monter les partitions en noatime lorsque c'est peu gênant. Jouer avec atop.

- Supprimer toute activité inutile sur le serveur (daemons, processus récurrents, crontab...)

- Enfin on peut downclocker le CPU, le bus et la mémoire; mais cela peut avoir des impacts sur la stabilité du système.

A titre de comparaison, j'ai un serveur avec 4 disques dur 3,5 pouces, un Céléron 2.4 GHz et 2.5 Go de ram; et la consommation tourne autour de 90 watts.

Tu veux dire qu'on n'a pas le droit d'acheter un Windows version OEM tout seul ?

Le refus de vente est interdit en France, de même que la vente liée, je ne vois pas pourquoi on ne retombe pas dans le même problème.

Je n'ai pas testé, mais essaye la solution du pauvre:

Crée des répertoires et des liens symboliques afin que même dans le chroot, on retrouve
/[mon chroot]/usr/java/jdk1.6.0_05/bin/../jre/lib/i686/libjli.so

S'il n'y a pas de sous-répertoire, ça donne:
cd /[mon chroot]/
ln -s . [mon chroot]

Sinon une autre solution si tu as de la place disque: c'est le debootstrap; ça permet d'installer une nouvelle version de debian dans un sous répertoire; ensuite tu peux faire un chroot dans ce répertoire.

Ca permet facilement d'essayer des version de JDK ou de librairies moins stables sans mettre le système principal en péril.

http://encombrants.paris.fr/

Tu réponds à deux ou trois questions, tu poses la télé sur le bord du trottoir le matin avant de partir au boulot; et la mairie l'enlèvent gratuitement.

Mes souvenirs remonte à 10 ans, a l'époque j'avais fait des trucs avec OpenSSL en stage.

Coté établissement de la session, il faut déployer correctement des certificats X509 des deux cotés. Si tu n'as pas besoin de certificats publics reconnus par tout le monde, tu crées un certificat racine qui va servir à signer; un certificat pour le client, et peut-être un pour le serveur (si tu veux aussi authentifier le serveur).

Ensuite il faut initier la connexion en demandant le bon mode d'authentification. D'un coté comme de l'autre, il faut exiger un certificat, sinon tu n'as que le chiffrement, et pas l'authentification. Pour ça, il me semble que la doc était bien suffisante, décrivant les appels de fonction à faire des deux cotés.

Ensuite tu as un flux qui fonctionne comme un flux TCP (je ne sais plus si le Out Of Band est supporté) et ton application en fait ce qu'elle veut, exactement comme si OpenSSL n'était pas là.

Je vois trois causes possibles :

-1- La carte ne supporte pas correctement le mode de fonctionnement imposé par le contrôleur IDE. C'est très souvent le cas pour les vieilles cartes Compact Flash que j'ai vu (Je n'ai jamais utilisé une carte moderne).
La norme ATA est implémentée de façon un peu légère; et bien que la carte annonce supporter certains mode; dans la réalité, ça se traduit par des erreurs, et parfois par des pertes de données. Le DMA est particulièrement sensible; mais même en ayant tout désactivé, j'ai encore des erreurs sans gravité sur certaines cartes.

-2- La carte a des problèmes. Un défaut de fabrication fait qu'une partie des secteurs ne fonctionne pas. Ce problème est difficile à diagnostiquer parce que:
- Les cartes CF ne supportent quasiment jamais SMART.
- La carte possède en réalité plus de secteurs que le nombre annoncé et fait en permanence du remappage pour distribuer les écritures; donc un secteur qui était défectueux et illisible redevient correct lors d'une ré-écriture.

-3- Le contrôleur a un bug qui se déclenche maintenant avec la nouvelle carte, je vois plus haut que le flashage du BIOS a déjà été envisagé.

Une remarque maintenant. Sur les systèmes à mémoire statique qui ne supportent pas un trop grand nombre d'écriture, on évite généralement d'utiliser un système de fichier journalisé, et on monte les FS en mode noatime pour réduire encore les écritures. Dans un système journalisé, on touche en permanence au journal sur le disque; conduisant à un grand nombre d'écritures.

Comme dit plus haut, la carte a plus de secteurs que le nombre annoncé et déplace continuellement les blocs lors des écritures pour répartir les écritures sur un maximum de secteurs; mais ça ne fait que retarder le problème
- cette répartition a des limites, surtout si le système de fichier est bien plein.
- la détection et le banissement des cellules effectivement mortes n'est pas forcément optimal; ou fait correctement.
- vu les marges sur ces produits, j'imagine qu'il y a des fabricants de mémoire qui n'hésitent pas à supprimer ce mécanisme ou à le réduire a sa plus simple expression.

L'unité de poids en mesure dans une grande partie du monde étant le gramme, on peut donc en conclure que le fichier VDI pèse 3,3 grammes après la mise à jour.

Si comme moi vous ne savez pas ce qu'est un fichier VDI, vous pouvez quand même essayer de faire des suppositions.

3,3 Go ? Ca n'a pas de sens, si c'était des Go, cela inclurait les fichiers de la distribution; or la place occupé par une distribution varie facilement d'un facteur 10 selon les paquets choisis; l'information n'a donc aucun sens. Si c'est l'image mémoire; c'est aussi un peu stupide; on s'attend à ce que ce soit paramétrable.

3.3 Mo ? C'est le fichier de configuration alors ? C'est un peu gros, il doit être écrit en XML.

3.3 sans unité, c'est généralement l'indication d'un rapport; c'est le facteur de ralentissement par rapport à la machine hôte ? Pas terrible.