WhiteCat a écrit 699 commentaires

Non j'ai fais le test hier avec mdadm et deux HDD :
1,5To et 3To et j'ai une partition de 4,5To (comme JBOD).
Je l'ai signalé dans ce message :)

Ah c'est vrai tu as raison ! Je ne le savais pas et je viens de faire le test sur une clé USB, apparemment (comme le dit "wismerhill") l'espace "en trop" n'est donc pas stripé.

Les logs noyaux parlent de "zones", dans mon test j'ai créé un RAID0 sur une partition de 64 Mo et de 100 Mo ce qui donne ces logs :

[ 4092.082890] sdd: sdd1 sdd2
[ 4095.086370] sdd: sdd1 sdd2
[ 4132.927349] md: bind
[ 4132.936888] md: bind
[ 4133.127778] md: raid0 personality registered for level 0
[ 4133.128204] md/raid0:md0: md_size is 317440 sectors.
[ 4133.128207] md: RAID0 configuration for md0 - 2 zones
[ 4133.128208] md: zone0=[sdd1/sdd2]
[ 4133.128211] zone-offset= 0KB, device-offset= 0KB, size= 122880KB
[ 4133.128212] md: zone1=[sdd2]
[ 4133.128214] zone-offset= 122880KB, device-offset= 61440KB, size= 35840KB
[ 4133.128224] md0: detected capacity change from 0 to 162529280

On voit donc que la 1ère zone est stripée sur 2 partitions pour 120 Mo et le reste (35 Mo) sur une partition.
Par contre je ne comprends pas pourquoi ma 1ère zone (celle qui est stripée) fait 120 Mo au lieu de 128 Mo (2 * 64 Mo) ?

Tout ceci n'a pas l'air documenté dans la doc kernel.org ni le man.

Ah, je ne connais pas encore celui-là. Tu as un petit retour d'expérience dessus? :)

Absolument aucun :-) J'en ai juste entendu parler récemment, ça avait l'air sympa comme idée. En gros tu peux avoir 2 disques avec chacun leur arborescence. Donc là on parle au niveau filesystem. Et avec AuFS tu peux créer un point de montage qui va fusionner ces 2 filesystem.
À part ça je peux pas vraiment t'en apprendre plus.

puis-je faire du non stripped (je ne veux pas que les fichiers soient découpé mais répartis)

Non, le RAID0 est bas niveau. Il ne voit pas tes fichiers. Si tu veux répartir tes fichiers faut gérer ça à plus haut niveau, par exemple avec GlusterFS ou AuFS.

puis-je ajouter/retirer des disques

Oui, d'après le man mdadm, tout ceci est possible.

les données présentent sur les autres disques sont-elles encore valable/utilisable si un disque crash

Non, c'est le principe du RAID0.

est-ce stable?

Oui.

puis-je additionner les disques comme un JBOD afin d'utiliser tout l'espace disponible ou suis-je limité par l'équation 2xplus petit disque = espace disponible -il se passe quoi si un disque (ou plusieurs) n'est pas présent au boot

Le RAID0 aura la taille du plus petit disque oui. Tu ne peux pas simplement agréger les disques comme en JBOD.
En revanche ce que tu peux faire, si imaginons que tu ais 4 disques :
2 disques de 750 Go
2 disques de 1 To

Tu fais un RAID0 de 3 To (= 4 tranches de 750 Go)
Il te reste donc 250 Go inutilisés sur chaque disque de 1 To. Tu peux très bien y faire un RAID0 de 500 Go (= 2 tranches de 250 Go) avec les espaces libres sur les 2 disques de 1 To.

il se passe quoi si un disque flanche en cours de fonctionnement?

Le RAID0 tombe et tu perds les données.

C'est pas faux.
Junior fait spécifiquement référence à la jeunesse, je n'y avais pas pensé.

Ça fait pas du tout référence à l'age, mais à l'expérience professionnelle.

C'est dans quelle ville ?
On peut faire du télé-travail ?

Ah et j'oubliais. Si tu veux faire ça encore plus proprement, tu peux même intervertir les câbles SATA du HDD et du SSD entre l'étape 7 et 8 (avant de booter Windows quoi). Comme ça Windows sera un peu moins perturbé car il sera toujours sur le même port SATA qu'avant.

Ceci dit il va quand même voir que le disque a changé et va sûrement te demander de rebooter au 1er démarrage.

Aucune idée désolé. Je connais trop peu Windows 8/10.

OK c'est bien ce que j'en avais déduis.

Du coup, voilà comment j'aurais procéder personnellement.
Cela va sans dire que je te conseille vivement de faire une sauvegarde du HDD avant, car les opérations ci-dessous sont non réversibles. Notamment j'ai un léger doute sur le fait que Windows retrouve vraiment bien la partition D (cf. ma remarque au point 8).

1) Réduire la partition C:
Tu peux le faire directement depuis le Windows en cours de fonctionnement, avec l'outil de gestion de disque Windows. Il te permet de réduire la taille de la partition C. Il va te dire de combien tu peux le réduire au maximum.
Il faudrait la réduire au minimum à un peu moins de la taille du SSD, mais en fait le mieux est carrément de réduire la partition au maximum possible. Ça évitera de copier trop de données vers le SSD lors du transfert (si on peut éviter "d'user" les cellules du SSD c'est pas plus mal, et la copie sera forcément plus rapide aussi).
Si tu ne peux pas réduire la partition à la taille du SSD, ben… va falloir supprimer des trucs sur le C. Ou alors essayer la réduction offline avec GParted LiveCD par exemple.
Une défragmentation du C peut être utile aussi je pense.

2) Copier le MBR sur le SSD
Tu bootes avec un LiveCD quelconque, afin de copier le MBR du HDD vers le SSD.
Perso je fais ça avec dd.

Tu repères avec parted qui est /dev/sda et /dev/sdb entre le HDD et le SSD.
# parted -l

(dans la suite je pars du principe que sdY = HDD, et sdX = SSD)
(et que la partition 1 correspond à la partition cachée Windows, 2 au C: et 3 au D:)

Et tu fais la copie du MBR :
# dd if=/dev/sdY of=/dev/sdX bs=4M count=1 && sync

Ouais je sais le MBR ne fait pas 4 MB mais disons que c'est pour être sûr de tout copier le début du disque en fait, on s'en fou de copier "trop" à ce moment-là.

Maintenant si tu refais un parted -l tu devrais voir que ton SSD dispose des mêmes partitions que le HDD. Là par contre je ne sais pas si tu vas avoir un message d'erreur ou pas étant donné que la partition D devrait être complètement hors du SSD.

3) Supprimer la partition D: du SSD
La partition D sur le SSD ne doit pas exister.

Tu repères quel est le numéro de partition D du SSD avec parted :
# parted -l

Tu supprimes avec parted :
# parted /dev/sdX (tu remplaces sdX avec ce qui correspond au SSD)
> rm 3 (correspond au numéro de partition de D:, à toi d'adapter le numéro en fonction de ce qu'il y aura chez toi)
> q (pour quitter)

4) Copier la partition cachée Windows
Comme d'hab', tu repères avec parted que le numéro de partition qui correspond à la partition cachée de Windows, et tu la copies avec dd du HDD vers le SSD :
# dd if=/dev/sdY1 of=/dev/sdX1 bs=8M && sync

5) Copier la partition C
Là, pareil qu'au-dessus :
# dd if=/dev/sdY2 of=/dev/sdX2 bs=8M && sync

6) Supprimer la partition cachée du HDD
Tu supprimes avec parted :
# parted /dev/sdY (tu remplaces sdY avec ce qui correspond au HDD)
> rm 1 (correspond au numéro de partition cachée de Windows, à toi d'adapter le numéro en fonction de ce qu'il y aura chez toi)
> q (pour quitter)

7) Supprimer la partition C du HDD
Tu supprimes avec parted :
# parted /dev/sdY (tu remplaces sdY avec ce qui correspond au HDD)
> rm 2 (correspond au numéro de partition de C:, à toi d'adapter le numéro en fonction de ce qu'il y aura chez toi)
> q (pour quitter)

8) Rebooter sur Windows (SSD)
Il est possible qu'il y ai chkdsk qui se lance au boot de Windows, rien d'anormal.
Une fois sur Windows il suffit de vérifier que ça fonctionne :-) et que le disque D est opérationnel aussi. Je pense que Windows devrait s'y retrouver mais j'ai pas testé donc peut-être que je suis trop optimiste…

9) Agrandir les partitions C et D
Tu peux le faire soit en online depuis Windows comme pour l'étape 1.
Ou bien en offline avec un LiveCD de GParted par exemple.
Pour l'agrandissement du D, penses à laisser 1 ou 2 Mio de dispo au début du disque, pour être sûr que le système de fichiers soit bien aligné sur les secteurs du HDD.

10) Faire un chkdsk sur C et D
Ça mange pas de pain.

Si je comprends bien, il n'y a pas de Linux sur ce HDD ?
Et tu veux transférer sur le SSD la partition "réservée" Windows (celle qui fait une centaine de Mo) ainsi que la partition Windows elle-même (C:). Mais laisser la dernière partition sur le HDD ?

Et il dit justement qu'à part "l'usage de logiciels libres", c'est générique (ça pourrait être une boite qui fait des ménages ou une boite qui vend des gadgets ou du logiciel non libre, c'est pareil) et qu'il n'y a rien qui soit spécifique au libre. Le libre ici est comme la couleur des cheveux du personnage principal d'un roman, c'est de la description optionnelle qui n'apporte rien au sujet.

Détrompes-toi. J'aime beaucoup sa série de témoignage justement parce qu'il raconte son histoire vis-à-vis d'une entreprise qui essaye de vivre du libre.
Il aurait raconté la même histoire pour sa boite qui fait du logiciel propriétaire, j'en aurais eu strictement rien à foutre, quand bien même il aurait rencontré les mêmes difficultés et problématiques.

Bonsoir,

Pour répondre à tes questions, je te conseille vivement de regarder ces 2 excellentes vidéos :
Le Bitcoin et la Blockchain (avec Heu?Reka) — Science étonnante #31
Bitcoin - Heu?reka #13

Pour ta dernière question je ne vois pas de quoi tu parles. Il n'y a pas de serveur à choisir pour entrer dans le réseau Bitcoin.

Si tu peux, prends une distrib' 64 bits. Ça te fera des performances "gratuites" en plus.

Et vérifie si ton BIOS est à jour, c'est toujours une bonne chose de le mettre à jour.

Par rapport à tes disques, il serait pas mal de vérifier leur "état de santé". Sous Linux, tu peux exécuter ces commandes :

# smartctl --all /dev/sda ; smartctl --all /dev/sdb

(si tu as 2 disques, il est très probable qu'il soit nommé sda et sdb, sinon tu adaptes la commande)
Dans le résultat de la commande, il faut surtout vérifier le nombre de secteurs défectueux.

Enfin, tu peux vérifier s'il n'y a pas de problème d'accès avec cette commande :

# dmesg |grep ata

J'espère juste que t'as pas pris un SSD Corsair Force LS.

Bonsoir,

Vu le message, moi je me serais dit que c'est un problème de lecture de la clé USB.
Essaye avec une autre clé USB si tu peux, voire même un CD/DVD.

Essaye dans un autre port USB aussi, notamment si c'est du USB 3.0 là, essaye dans un port USB 2.0.

Vérifie que ton BIOS est à jour aussi.

Et aussi l’anecdotique Windows XP x64, en 2005, basé sur XP SP2.

Basé sur Windows 2003 Server plutôt (noyau NT 5.2).

Un benchmark honnête serait par exemple de faire tourner x265 sans le code optimisé à la main… Enfin si phoronix savait comment faire des benchs ça se saurait :P

Ça s'appelle pas un benchmark honnête, mais simplement un autre benchmark.
Phoronix est plutôt irréprochable sur la méthodologie de ses benchmarks. Personnellement je ne vois pas trop quoi y redire. Après c'est le choix des benchmarks qui semblent te poser problème, mais c'est un autre problème qui n'a rien à voir avec la méthodologie elle-même.

Ça en fait toujours une de moins qu'en 64bits ;-)

C'est pas faux ;)

En l'occurrence, ça m'étonnerait pas que x265 soit plus rapide en i386.

Je n'ai aucune raison rationnelle de croire cela.
Donc j’attends de voir un benchmark pour te croire sur parole.

Le problème du trésorier: quelle est la version de linux la plus compatible à offrir à mon publique -> satisfaction de Mme Michu.

Et c'est bien pour ça que j'ai posté sur ce forum. Pour dire qu'à mon sens il se trompe. S'il veut veut offrir la meilleure expérience à Mme Michu, c'est certainement pas en lui installant un Linux 32 bits sur son portable Haswell 8 Go…

Le problème de Linus: comment faire pour avoir un système le plus performant sur le matériel actuel -> est-ce vraiment pour Mme Michu ?

Et aussi le moins bugué. Or quand on essaye de faire tourner un OS sur une machine récente (avec beaucoup de RAM, genre + de 2 Go), l'AMD64 semble plus simple à gérer du point de vue de l'OS, donc moins de bug.

ben si ça se trouve i386 ou x32 sur du matos 64bit avec PAE activé sera plus performant qu'une autre solution.

En x32 c'est bien possible. En PAE j'en doute étant donné que le PAE rajoute une 3ème indirection mémoire que le CPU doit traiter en plus.

Je réponds à côté de la plaque parce que j'ai pas du tout compris où tu voulais en venir avec tes explications sur le PAE.

Moi, avec mes extraits de citations, je voulais simplement indiquer que si un expert en memory management x86 dit que tout le monde (comprendre "Mme Michu") devrait tourner en 64 bits, alors je trouve un peu à côté de la plaque qu'un trésorier d'une asso Linux en 2016 grave encore des DVD 32 bits pour le grand public. C'est tout.

Et c'est pas pour autant que je souhaite le mort totale du 32 bits x86. J'espère que Debian le supportera longtemps encore (ça j'en suis presque sûr de toute façon), ça servira probablement toujours à quelqu'un.

Tu n'as pourtant pas répondu à la question de pourquoi faire, oui ou non, du PAE entre 1 et 4GB ?

Je sais pas. J'ai pas l'impression que la réponse est dans mon lien, si ?
Le seul intérêt, je dirais, c'est de pouvoir utiliser le NX-bit.

Non parce que tu peux t'appeler Albert Einstein et te tromper totalement quand tu parle de physique fondamentale.

Albert Einstein n'a pas créé/inventé lui-même les lois de la physique. Donc quand il en parle il peut se tromper oui, ça n'a rien d'étonnant.

Quand Linus parle de la gestion mémoire de l'architecture x86 et Linux, là ça serait étonnant qu'il se trompe dans ces propos.

(Question à 5 francs: pourquoi choisit-il la valeur de 1 GO ?)

Il l'explique ici : http://www.realworldtech.com/forum/?threadid=76912&curpostid=76980

Il me semblait que c'était pas spécifique à Windows, mais à l'architecture AMD64 qui ne permet pas de faire tourner du code 16 bits en mode 64 bits. Non ?