Les disques SSD c'est bien, c'est super-rapide, mais cela souffre d'un certain handicap après de nombreuses mises à jour. Le contrôleur interne du SSD essaye de répartir l'utilisation des "blocs" afin de ne pas avoir un bloc ré-écrit en permanence qui ne manquerait pas de "s'user" avant les autres. 
Le contrôleur interne du SSD a donc "besoin" de connaitre les blocs libérés afin de pouvoir les ré-attribuer. Or les systèmes de gestion de fichiers de Linux, s'ils libèrent les blocs d'un fichier détruit (et enregistrent ces blocs comme "libres) n'en informent pas le contrôleur interne du SSD, celui-ci se trouve donc, au bout d'un certain temps, "à court" de blocs qu'il sait pouvoir réattribuer. 
Cet état de fait est très préjudiciable à la performance (surtout en écriture) lorsque le disque a un peu vécu. 
Heureusement on trouve sur Sourceforge au sein du projet "hdparm" un logiciel (wiper) qui permet de transmettre au contrôleur interne du SSD les renseignements voulus (http://sourceforge.net/projects/hdparm/files/wiper-2.6.tar.gz) qui permet de réaliser l'opération. 
Le seul problème est que mon disque (OCZ Vertex) était un peu "ancien" (version firmware 1.4) et qu'il faut être au moins en 1.5). Heureusement, OCZ a publié une image ISO qui permet de réaliser cette opération délicate, on peut la trouver à (http://www.ocztechnologyforum.com/staff/ryderocz/vertex/vertex_15.zip) qu'il faut dézipper, graver en ISO. Il faut ensuite booter sur le CD avec le SSD monté, le reste est expliqué sur l'écran, attention tous les SSD Vertex (même en version 1.4) ne sont pas "capables" de recevoir cette mise à niveau (???). 
Nouveauté 1: il existe sur le site une version pour SSD "récalcitrants" (avec "fail" dans le nom, j'en avais un qui refusait la mise à jour "standard", avec cette version l'affreux SSD a parfaitement été mis à jour. 
Nouveauté 2 : il existe maintenant une version 1.6 du soft des SSD que je vais essayer à l'occasion. 

Attention, ces manipulations peuvent entraîner une perte de données !!! Un bon backup est nécessaire !!! 
Dans mon cas où il s'agissait du disque "système", j'en ai réalisé une copie conforme sur un "vieux" disque SATA (dd est un très bon ami à moi) que j'ai ensuite testé (faut que ça boote !), avant de tenter les manip : "upgrade version firmware SSD" et "wiper". 
Ces manipulations devraient disparaître peu à peu en fonction de l'évolution des noyaux, (il existe des outils intégrés pour Windows 7) et le noyau Linux devrait rapidement prendre en compte cette option. 
En attendant il est nécessaire de recourir à des manipulations assez peu orthodoxes. Si on peut "wiperiser" un disque démonté il n'est pas possible de la faire sur le disque système, le mieux est probablement de disposer d'un CD (ou clé USB) avec un système minimal et le très fameux WIPER. 
Toutefois il n'est pas besion d'exécuer cette manip tous les jours ! Sur un disque très chargé en écriture comme le mien (cela s'est calmé depuis) il a fallu plusieurs mois avant de ressentir le ralentissement en écriture, la lecture restait OK. 
J'ai refait les tests "iozone" (il faut conserver les scripts !) lors desquels j'avais trouvé des performances "horribles" en écriture sur une machine et les résultats sont là : il faut trimer pour que le disque bosse à la vitesse max. 
Note : cette machine avait servi à de nombreuses compilations (et installations) de noyaux et de différentes version de XEN, opérations qui réalisent énormément d'écritures. 

Voici deux séries d'image dans le style AVANT/APRES bien connu des publicitaires .... mais ce n'est pas du rêve, c'est bien la réalité

 

Avant	Après
"Write"
Random Write
Record Write

C'est assez spectaculaire, et c'est bien, physiquement, le même disque ... vive le TRIM. 

Une séance de trim : 
1) Test sans valider, "pour voir" 
# ./wiper.sh /dev/sdb2                                                 

wiper.sh: Linux SATA SSD TRIM utility, version 2.6, by Mark Lord. 
Hdparm version 
Target=/dev/sdb2 Method=offline 
Preparing for offline TRIM of free space on /dev/sdb2 (ext3 non-mounted). 
This will be a DRY-RUN only.  Use --commit to do it for real. 
Syncing disks.. 
Simulating TRIM operations.. 
(dry-run) trimming 37690664 sectors from 8058 ranges 
Done. 
2) Un passage "en vrai" : 
./wiper.sh /dev/sdb2 --commit 

wiper.sh: Linux SATA SSD TRIM utility, version 2.6, by Mark Lord. 
Hdparm version 
Target=/dev/sdb2 Method=offline 
Preparing for offline TRIM of free space on /dev/sdb2 (ext3 non-mounted). 

This operation could silently destroy your data.  Are you sure (y/N)? y 
Syncing disks.. 
Beginning TRIM operations.. 

/dev/sdb: 
trimming 37690664 sectors from 8058 ranges 
succeeded 
Done.

Et en plus c'est très rapide, moins d'une minute. Le seul problème est que cela ne fonctionne pas sur un disque monté et un disque système non monté c'est légèrement gênant !

Mais si l'on a un autre disque bootable il n'y a aucun problème, on peut aussi démarrer sur un Live CD sur lequel on a installé le logiciel adéquat. J'ai deux disques bootables sur deux versions différentes du système dont une "stable", donc pas de problème de ce coté.

Le support du "TRIM" est partiel depuis le noyau 2.6.32 et limité aux filesystems "btrfs" (2.6.32) et "ext4" (2.6.33) en utilisant l'option "discard" dans la déclaration du périphérique dans "fstab", exemple :

/dev/sda1 / ext4 defaults,noatime,discard 0 0

Il va falloir passer le disque système en ext4, est-ce déjà judicieux ?

Le "TRIM" est toujours important mais les noyaux et les" file systems" récents offrent des possibilités d'automatisation des actions de TRIM. 
Au niveau du fichier "fstab" : 
L'apparition d'une nouvelle possibilité "discard" permet d'automatiser la gestion du TRIM en la laissant au système, il faut pour cela disposer de noyaux assez récents et je ne sais plus quelle version a apporté cette nouveauté. 
Exemple de déclaration "fstab" :

LABEL=LOG1    /LOG/LOG1   ext4    auto,noatime,relatime,discard    2    0

Au niveau de LVM : 
Il est là aussi possible de spécifier une option automatisant le TRIM au niveau de LVM, ceci se fait dans le fichier "lvm.conf". 
Exemple de déclaration dans le fichier /etc/lvm/lvm.conf : 
issue_discards = 1 
Ce fichier est par ailleurs très bien commenté (au moins sur une Debian).

Après ces petites interventions, et un reboot, plus de soucis de trim sur vos beaux SSD qui garderont une performance optimale, probablement au prix d'une légère diminution de leur durée de vie.

Ce "Livre" regroupe quelques articles sur le "TRIM", le premier, très ancien, vous pensez il remonte à 2010. 
Il y a eu pas mal de nouveautés, tant au niveau du système que du matériel que j'mis un "chapeau" au premier article et écrit un nouvel article en montrant les possibilités des noyaux Linux récents.

Le premier article de 2010.

Une description récente des possibilités tant au niveau de la "fstab" que de LVM.

Les tests ont été refaits avec de nouveaux noyaux. 
La première série de tests a été réalisée avec l'utilitaire "hdparm" dont l'option "-t" permet de mesurer un débit IO en lecture. 
Pour les machines que j'ai utilisées il s'agit des disques sda,sdb,sdc,sdd. L'une de ces machines est munie de disques en miroir, il a donc été nécessaire d'agir sur deux disques simultanément pour changer de scheduler. 
Premier test. 
Les résultats sont les suivants (valeurs en MO/seconde, le plus fort est le mieux !) : 

 

RAM 8GO			Quadcore kernel 2.6.30-2
hdparm		hdparm	hdparm	hdparm	TOTAL
SSD RAID	Noop	115,51	107,73	104,52	327,76	33,564%	X
	CFQ	100,90	107,83	114,66	323,39	33,117%
	Deadline	119,11	100,42	105,84	325,37	33,319%
		335,52	315,98	325,02	976,52
SATA RAID	Noop	75,59	75,29	75,11	225,99	33,481%	X
	CFQ	75,25	73,39	75,66	224,30	33,231%
	Deadline	76,06	75,11	73,52	224,69	33,288%
		226,90	223,79	224,29	674,98	SATA/SSD	69,12%
RAM 8GO			Dualcore kernel 2.6.31
hdparm		hdparm	hdparm	hdparm	TOTAL
SSD	Noop	133,35	132,61	131,89	397,85	33,241%
	CFQ	131,36	132,33	134,13	397,82	33,238%
	Deadline	133,63	133,96	133,61	401,20	33,521%	X
		398,34	398,90	399,63	1196,87
SATA RAID	Noop	68,91	69,31	69,29	207,51	32,097%
	CFQ	73,13	73,26	73,15	219,54	33,958%	X
	Deadline	73,12	73,03	73,31	219,46	33,945%
		215,16	215,60	215,75	646,51	SATA/SSD	54,02%
RAM 8GO			Quadcore kernel 2.6.32
hdparm		hdparm	hdparm	hdparm	TOTAL
SSD RAID	Noop	77,18	61,33	71,93	210,44	27,693%
	CFQ	79,72	102,37	98,66	280,75	36,946%	X
	Deadline	75,83	92,08	100,79	268,70	35,360%
		232,73	255,78	271,38	759,89
SATA RAID	Noop	75,25	74,33	73,52	223,10	33,258%
	CFQ	73,47	75,73	75,64	224,84	33,517%	X
	Deadline	75,77	73,64	73,47	222,88	33,225%
		224,49	223,70	222,63	670,82	SATA/SSD	88,28%
RAM 8GO			Quadcore kernel 2.6.33-rc5
hdparm		hdparm	hdparm	hdparm	TOTAL
SSD RAID	Noop	71,98	75,83	92,32	240,13	36,264%
	CFQ	60,95	60,86	59,73	181,54	27,416%
	Deadline	89,27	76,18	75,06	240,51	36,321%	X
		222,20	212,87	227,11	662,18
SATA RAID	Noop	73,52	74,34	75,82	223,68	33,373%
	CFQ	76,77	73,98	73,80	224,55	33,502%	X
	Deadline	73,43	75,21	73,38	222,02	33,125%
		223,72	223,53	223,00	670,25	SATA/SSD	101,22%

 

Constatation 1 : 
Les résultats sont très serrés, les différences sont peu marquantes et ne font en général que quelques pourcents. 
Constatation 2 : 
Les résultats sont différents sur la même machine avec des noyaux différents. 
Constatation 3 : 
Les résultats SSD sont meilleurs sur le Dualcore ... c'est normal, il ne s'agit pas du même SSD mais  d'un modèle vendu comme plus performant (et cela a l'air vrai) ... mais malheureusement nettement plus cher. 
Les résultats obtenus avec un noyau  > 2.6.32 sont un peu bizarres, à partir du 2.6.33 un des schedulers a disparu, je n'ai pas trouvé trace du "anticipatory scheduler", il ne reste que NOOP, CFQ et DEADLINE, les résultats sont comme pour le 2.6.32 très bizarres sur la partie SSD et se tiennent bien sur la partie SATA. J'ai oté toutes référence au scheduler "anticipatory" pour avoir des tableaux comparables sur toutes les versions. 

Le SSD présente des anomalies importantes de vitesse sur les noyaux récents :

• Noyau 2.6.32 
  • Mini de 61,33
  • Maxi de 102,37 soit un écart de plus de 60% !
  • Alors que la partie SATA présente un écart inférieur à 3%.
• Noyau 2.6.33
  • Mini de 59,73
  • Maxi de 92,32 soit un écart de près de 60%
  • Alors que la partie SATA présente un écart inférieur à 5%.

Les tests "hdparm" semblent complètement dépassés pour les dernières versions du noyau. Les indications relatives de ce test ne sont valables que pour les noyaux < 2.6.32. D'autre part les améliorations apportées par les noyaux >= 2.6.32 sont bel et bien ressenties à l'utilisation, voir les tests de compilation. 
Voir aussi la page sur les nouveaux tests "hdparm" éxécutés avec l'option " --direct" permettant d'utiliser plus directement le hardware. 
 

La première version des tests présentait des anomalies de performance et une grande irrégularité. J'ai "découvert" une option complémentaire de cet utilitaire ( --direct ) permettant d'atteindre plus directement le hardware en évitant le passage par les buffers système. Ce type d'option (utilisant le flag "O_DIRECT" du noyau) est d'ailleurs recommandé pour les bases de données afin d'éviter de multiples recopies en mémoire sources de perte de performance.

• Sans "O_DIRECT" les données effectuent le transit suivant : HARDWARE --> page cache --> programme utilisateur.
• Avec "O_DIRECT" le transit est plus direct : HARDWARE --> programme utilisateur

Cela se voit d'ailleurs dans les résultats qui représentent ainsi mieux les performances "brutes" du hardware (les valeurs indiquées sont en MO/seconde). 
Dualcore (SSD rapide) : 

RAM 8GO			Dualcore kernel 2.6.31
hdparm -t		1	2	3	TOTAL
SSD RAID	Noop	201,87	207,80	203,05	204,24	103,873%	X
	CFQ	154,12	202,68	204,47	187,09	95,151%
	Deadline	189,17	203,52	202,94	198,54	100,976%
		181,72	204,67	203,49	196,62
SATA RAID	Noop	73,50	69,23	73,48	72,07	100,721%	X
	CFQ	69,26	73,22	69,58	70,69	98,787%
	Deadline	73,20	69,32	73,20	71,91	100,492%
		71,99	70,59	72,09	71,55	SSD/SATA	274,79%
RAM 8GO			Dualcore kernel 2.6.33
hdparm -t		1	2	3	TOTAL
SSD RAID	Noop	201,06	202,40	201,43	201,63	101,058%	X
	CFQ	198,19	197,41	199,59	198,40	99,437%
	Deadline	198,50	198,60	198,50	198,53	99,505%
		199,25	199,47	199,84	199,52
SATA RAID	Noop	68,99	69,07	69,12	69,06	99,722%
	CFQ	69,06	69,54	69,31	69,30	100,074%
	Deadline	69,72	69,23	69,23	69,39	100,204%	X
		69,26	69,28	69,22	69,25	SSD/SATA	288,11%

Quadcore (SSD "lent") : 

RAM 8GO			Quadcore kernel 2.6.31
hdparm -t		1	2	3	TOTAL
SSD RAID	Noop	144,79	144,42	101,67	130,29	105,715%	X
	CFQ	125,20	144,35	101,65	123,73	100,392%
	Deadline	144,39	101,12	101,66	115,72	93,893%
		138,13	129,96	101,66	123,25
SATA RAID	Noop	75,62	73,62	76,04	75,09	100,341%
	CFQ	73,41	75,83	73,54	74,26	99,228%
	Deadline	75,83	73,58	76,07	75,16	100,431%	X
		74,95	74,34	75,22	74,84	SSD/SATA	164,69%
RAM 8GO			Quadcore kernel 2.6.33
hdparm -t		1	2	3	TOTAL
SSD RAID	Noop	137,88	137,87	137,87	137,87	103,297%	X
	CFQ	137,85	137,84	137,86	137,85	103,280%
	Deadline	137,82	137,87	98,39	124,69	93,423%
		137,85	137,86	124,71	133,47
SATA RAID	Noop	75,78	75,85	75,87	75,83	100,066%	X
	CFQ	75,71	75,69	75,81	75,74	99,938%
	Deadline	75,78	75,71	75,85	75,78	99,996%
		75,76	75,75	75,69	75,78	SSD/SATA	176,12%

Les résultats sont un peu irréguliers pour le SSD ce qui "baisse" la moyenne à 123MO/seconde en 2.6.31 et 133MO/seconde pour le noyau 2.6.33. 
Autre machine (ATOM N330) : 
J'ai fait faire les tests sur un nouveau "petit" serveur (ATOM N330) avec lequel on obtient les résultats suivants : 

RAM 2GO			MINIITX kernel 2.6.33
hdparm -t		1	2	3	TOTAL
SSD RAID	Noop	148,34	152,50	149,89	150,24	100,647%	X
	CFQ	149,63	154,00	143,41	149,01	99,823%
	Deadline	144,02	148,59	153,12	148,58	99,530%
		147,33	151,70	148,81	149,28
SATA RAID	Noop	73,59	73,52	73,33	73,48	100,041%	X
	CFQ	73,52	73,56	73,35	73,48	100,036%
	Deadline	73,30	73,45	73,43	73,39	99,923%
		73,47	73,51	73,37	73,45	SSD/SATA	203,24%

Ce qui n'est pas mal du tout pour une petite machine. 
Il a juste fallu ajouter un disque SATA de 160Go (8Mo cache) dans la belle boîte pour faire ces tests.

Deuxième test. 
Devant ces résultats un peu théoriques j'ai essayé de faire d'autres mesures peut-être plus représentatives. J'ai donc mesuré le temps de "dézipper" et de "rezipper" les sources du noyau "linux-2.6.31.6.tar.gz" soit à peu près 79Mo zippés et # 380Mo dézippés. 
Les commandes exécutées sont : 
sync 
cd $REP 
gzip -d linux-2.6.31.6.tar.gz 
sync 
gzip linux-2.6.31.6.tar 
sync 

Et la durée "ellapsed" de l'ensemble est mesurée par la commande "time" dont le résultat "real" est repris dans les tableaux. 
Trois séries de tests ont été exécutées pour chacun des schedulers disponibles.  

RAM 8GO			Quadcore kernel 2.6.30.2
Gzip		Gzip	Gzip	Gzip	TOTAL
SSD RAID	Noop	38,20	35,14	36,03	109,37	24,726%	X	24,726%
	CFQ	38,06	37,20	36,50	111,76	25,267%
	Anticip	36,84	36,20	37,17	110,21	24,916%
	Deadline	38,89	36,07	36,02	110,98	25,091%
		151,99	144,61	145,72	442,32
SATA RAID	Noop	25,88	26,08	26,14	78,10	25,006%		24,853%
	CFQ	26,21	26,11	26,25	78,57	25,157%
	Anticip	25,90	25,95	26,18	78,03	24,984%
	Deadline	25,48	26,03	26,11	77,62	24,853%	X
		103,47	104,17	104,68	312,32
RAM 3GO			Quadcore kernel 2.6.31.4-xen (XEN)
Gzip		Gzip	Gzip	Gzip	TOTAL
SSD RAID	Noop	69,62	67,71	69,00	206,33	25,056%		24,801%
	CFQ	69,13	68,31	66,79	204,23	24,801%	X
	Anticip	69,78	67,77	69,32	206,87	25,122%
	Deadline	68,94	68,85	68,25	206,04	25,021%
		277,47	272,64	273,36	823,47
SATA RAID	Noop	58,96	58,30	58,65	175,91	24,999%	X	24,999%
	CFQ	58,43	58,91	58,58	175,92	25,000%
	Anticip	58,67	58,53	58,71	175,91	24,999%	X
	Deadline	58,30	59,51	58,12	175,93	25,002%
		234,36	235,25	234,06	703,67
RAM 8GO			Quadcore kernel 2.6.31.4-xen (XEN)
Gzip		Gzip	Gzip	Gzip	TOTAL
SSD RAID	Noop	73,08	74,02	71,39	218,49	24,943%		24,904%
	CFQ	74,30	72,18	73,82	220,30	25,150%
	Anticip	72,62	72,90	73,50	219,02	25,003%
	Deadline	73,35	73,03	71,77	218,15	24,904%	X
		293,35	292,13	290,48	875,96
SATA RAID	Noop	62,21	62,09	62,24	186,54	24,985%	X	24,985%
	CFQ	62,08	61,62	63,18	186,88	25,030%
	Anticip	62,09	61,70	62,85	186,64	24,998%
	Deadline	63,08	61,90	61,57	186,55	24,986%
		249,46	247,31	249,84	746,61

Les résultats montrent que les SSD ne gagnent pas toujours ! Curieusement tous les tests sur le disque SSD sont très nettement moins bons, presque deux fois moins rapides !

Devant les différents points d'interrogation posés par les tests précédents j'ai décidé de faire d'autres tests encore plus près de "la vie réelle" en réalisant un petit exercice de compilation. 
J'ai pris comme "cobaye" le logiciel IPERF dans sa version 2.0.4 et réalisé les opérations suivantes :

• Création d'un répertoire de compilation sur le SSD /var/tmp/iperf-2.0.4
• Création d'un répertoire de compilation sur le disque SATA /RAIDZZZ/tempo/iperf-2.0.4

Chacun de ces répertoires comporte bien entendu l'arbre des sources de IPERF et une compilation a été réalisée "à la main". Les opérations réalisées par le script (mesurées par la commande "time" ) seront : 
sync 
cd $REP 
make clean 
rm -f config.status 
./configure 
make -j 2 
sync 
Les temps "real" figurent dans le tableau suivant ( valeurs en secondes, le plus faible est le mieux) :

RAM 8GO			Dualcore kernel 2.6.31
Compil		Compil	Compil	Compil	TOTAL
SSD RAID	Noop	14,98	15,30	15,08	45,36	33,324%		33,257%
	CFQ	15,02	15,17	15,08	45,27	33,257%	X
	Deadline	15,17	15,19	15,13	45,49	33,419%
		45,17	45,66	45,29	136,12
SATA RAID	Noop	15,86	15,91	15,85	47,62	33,649%		33,154%
	CFQ	15,83	15,82	15,27	46,92	33,154%	X
	Deadline	15,93	15,33	15,72	46,98	33,197%
		47,62	47,06	46,84	141,52	SATA/SSD	103,97%
RAM 3GO			Quadcore kernel 2.6.31-4-xen
Compil		Compil	Compil	Compil	TOTAL
SSD RAID	Noop	28,80	27,86	27,71	84,37	33,190%		33,068%
	CFQ	27,89	28,30	27,87	84,06	33,068%	X
	Deadline	28,18	28,32	29,27	85,77	33,741%
		84,87	84,48	84,85	254,20
SATA RAID	Noop	28,83	28,17	27,93	84,93	33,377%		33,149%
	CFQ	28,27	28,52	28,39	85,18	33,475%
	Deadline	27,97	27,82	28,56	84,35	33,149%	X
		85,07	84,51	84,88	254,46	SATA/SSD	100,10%
RAM 3GO			Dualcore kernel 2.6.31-8-xen
Compil		Compil	Compil	Compil	TOTAL
SSD RAID	Noop	14,34	15,20	15,19	44,73	33,116%	X	33,116%
	CFQ	15,11	15,13	15,23	45,47	33,664%
	Deadline	14,84	15,11	14,92	44,87	33,220%
		44,29	45,44	45,34	135,07
SATA RAID	Noop	16,59	15,83	16,65	49,07	34,152%		32,719%
	CFQ	15,87	15,44	15,70	47,01	32,719%	X
	Deadline	15,85	15,90	15,85	47,60	33,129%
		48,31	47,17	48,20	143,68	SATA/SSD	106,37%
RAM 8GO			Quadcore kernel 2.6.30-2
Compil		Compil	Compil	Compil	TOTAL
SSD RAID	Noop	14,48	14,39	14,28	43,15	33,538%		33,103%
	CFQ	14,24	14,07	14,28	42,59	33,103%	X
	Deadline	14,26	14,45	14,21	42,92	33,359%
		42,98	42,91	42,77	128,66
SATA RAID	Noop	14,70	15,46	15,08	45,24	34,066%		32,937%
	CFQ	14,28	14,11	15,43	43,82	32,997%
	Deadline	14,35	14,79	14,60	43,74	32,937%	X
		43,33	44,36	45,11	132,80	SATA/SSD	103,22%
RAM 8GO			Quadcore kernel 2.6.32
Compil		Compil	Compil	Compil	TOTAL
SSD RAID	Noop	11,09	10,38	10,24	31,71	34,031%		32,958%
	CFQ	10,19	10,33	10,19	30,71	32,958%	X
	Deadline	10,33	10,26	10,17	30,76	33,011%
		31,61	30,97	30,60	93,18
SATA RAID	Noop	11,69	10,88	10,95	33,52	33,924%		32,952%
	CFQ	10,81	10,87	10,88	32,56	32,952%	X
	Deadline	10,97	10,90	10,86	32,73	33,124%
		33,47	32,65	32,69	98,81	SATA/SSD	106,04%
RAM 8GO			Quadcore kernel 2.6.33-rc5
Compil		Compil	Compil	Compil	TOTAL
SSD RAID	Noop	10,17	10,16	10,21	30,54	33,217%	X	33,217%
	CFQ	10,22	10,30	10,29	30,81	33,511%
	Deadline	10,17	10,17	10,25	30,59	33,272%
		30,56	30,63	30,75	91,94
SATA RAID	Noop	10,22	10,28	10,30	30,80	33,315%	X	33,315%
	CFQ	10,25	10,30	10,30	30,85	33,369%
	Deadline	10,22	10,28	10,30	30,80	33,315%	X
		30,69	30,86	30,90	92,45	SATA/SSD	100,55%
RAM 8GO			Dualcore kernel 2.6.33-rc6
Compil		Compil	Compil	Compil	TOTAL
SSD RAID	Noop	12,62	12,19	12,06	36,87	33,601%		32,963%
	CFQ	12,00	12,19	11,98	36,17	32,963%	X
	Deadline	12,02	12,21	12,46	36,69	33,437%
		36,64	36,59	36,50	109,73
SATA RAID	Noop	13,73	13,08	12,37	39,18	33,313%		32,829%
	CFQ	13,11	13,61	13,10	39,82	33,858%
	Deadline	12,74	12,81	13,06	38,61	32,829%	X
		39,58	39,50	38,53	117,61	SATA/SSD	107,18%

Par ailleurs les différences entre les différents scheduler d'IO ne sont pas significatives sur ces tests car elles restent inférieures à 1%.Les temps sont meilleurs pour les deux types de disques dans les montées de version du noyau Linux. 
Le temps total (9 exécutions) passe de #92 secondes pour le noyau 2.6.33 à #95 pour le 2.6.32 à #130 secondes pour le 2.6.30. Visiblement les développeurs du noyau ont bien travaillé et les progrès sont nettement visibles. 
Cette série de tests montre un léger avantage au SSD par apport au disque "classique" une différence de 4 à 6% se manifeste en sa faveur.

La construction des tests progresse, les groupes de valeurs ont été choisis :

• Taille des fichiers testés : 4, 8, 16, 32, 64, 128, 256, 512 et 1024 MégaOctets
• Taille des enregistrements : 16, 32, 64, 128, 256 et 512 octets

 Cela devrait donner des chiffres significatifs. Pour pouvoir effectuer ces tests pour plusieurs noyaux sur SSD et SATA classique un petit ensemble de scripts a été réalisé et pour présenter de jolis graphiques je me suis replongé dans "GNUPLOT" et après quelques scripts de traitement des données il me sera possible de présenter de jolis dessins. 
Par contre l'acquisition des tests est très longue et se chiffre en heures pour un seul passage complet de tests. 
Devant le peu de différences entre les différents schedulers les tests ne seront faits que pour le scheduler "noop", a priori le moins compliqué, qui devrait mieux représenter la performance "brute" des disques. 
Les petits dessins et quelques commentaires sous peu ... dès que l'ensemble des tests aura "tourné" et que quelques commentaires seront disponibles ... 
La commande utilisée ( ici fichier de 1024Mo, enregistrements de 32 caractères sur un disque SATA ) : 

iozone -s 1048576 -r 32 -f /tempo/testio -I -o -M

• -s Taille du fichier en KO
• -r taille de l'enregistrement en cacartères
• -f fichier de travail (sur disque SATA ou SSD)
• -I  Use VxFS VX_DIRECT, O_DIRECT,or O_DIRECTIO for all file operation
• -o  Writes are synch (O_SYNC)
• -M Report uname -a output

8

Les tests sont réalisés sur deux machines possédant chacune des disques SSD et des SATA classiques :

• Amd dualcore 4400+ à 2.20 Ghz, 8 Go RAM, contrôleur SATA nvidia CK804, avec un SSD très rapide et deux disques SATA 1To en RAID1 (miroir).
• Amd quadcore 905e à 2,5Ghz, 8Go Ram, contrôleur ATI SB700/SB800, avec un SSD plus standard et deux disques SATA assez anciens de 160Go en RAID1 (miroir).

Cà y est enfin, j'ai toutes les données nécessaires, le processus est très long ... deux à quatre heures pour chaque noyau. Et en plus il ne faut pas toucher la machine pendant la prise de données pour ne pas fausser les résultats. 
Les scripts préparés pour Gnuplot sont OK, ils génèrent bien les graphes escomptés, maintenant il faut essayer d'en extraire la quintessence pour la présenter. On peut déjà dire que certains résultats sont un peu curieux et n'ont pas d'explication immédiate, d'autres sont plus évidents et vont dans le sens prévu. Il semble toutefois que les disques SSD ne soient pas la panacée malgré un certain nombre d'avantages. 
Il semble par ailleurs que "iozone" soit partiellement inadapté aux disques modernes munis de cache très importants. Les disques SATA ont 8Mo de cache sur la machine quadcore et 32Mo sur la machine dualcore. Les caches des disques SSD sont encore plus volumineux : 64 Mo. 
Très bientôt les premiers résultats, la structure d'accueil est prête ...

Résultats en lecture, tous les résultats sont donnés pour les deux versions de noyau choisies 2.6.31 et 2.6.33. 
Dualcore

De grosses différences se manifestent, d'une part dans les "petits" fichiers où la taille du cache du disque semble prépondérante, le noyau 2.6.33 donne de superbes résultats sur le disque "classique" pour les petites tailles de fichiers, le SSD l'emporte dès que la taille des fichiers augmente. Le noyau 2.6.33 semble "brider" la performance du SSD. 
Remarque : le SSD semble plus beaucoup plus sensible à la taille des enregistrements, il prend l'avantage dès que la taille des enregistrements dépasse 128 octets. 

Quadcore :

La forme des courbes est beaucoup plus régulière que sur le dualcore, le SSD prends l'avantage dès les petites valeurs d'enregistrements et accentue son avance lorsque l'enregistrement s'allonge. 
La vitesse maxi du SSD est moindre que pour le dualcore, ce qui semble normal au vu des types de disques. La courbe des disques SATA est plus régulière et plus "pentue" que pour le dualcore, est-ce une influence de la taille de cache beaucoup plus réduite. 

Conclusion : avantage au SSD dès que la longueur des enregistrements dépasse 32, l'avantage s’accroît avec la taille des fichiers et celle des enregistrements.

Résultats en lecture "random", tous les résultats sont donnés pour les deux versions de noyau choisies 2.6.31 et 2.6.33. 
Dualcore

Les résultats sont bien ceux attendus, le SSD gagne haut la main. Le fait de ne pas avoir de délai rotationnel ni de temps de déplacement des têtes permet au SSD de dominer très largement dès que l'on sort un peu des caches (au delà de 32Mo). Le noyau 2.6.33 semble exploiter mieux les caches du disque "classique" pour les petits fichiers ( < taille du cache) où la vitesse atteint des sommets impressionnants. 

Quadcore :

Les caches plus petits des disques classiques donnent un aspect beaucoup plus "lisse" aux graphes, le SSD gagne là aussi haut la main quel que soit le noyau. Les résultats sont équivalents pour les deux noyaux testés. 

Conclusion : les disques SSD gagnent logiquement ce match, les délais (rotationnels et piste à piste) sont ici très défavorables qux disques "classiques".

Résultats en écriture, tous les résultats sont donnés pour les deux versions de noyau choisies 2.6.31 et 2.6.33. 
Dualcore

Des résultats curieux, l'avantage reste au SSD mais le noyau 2.6.33 donne de très bonnes performances au disque "classique" en exploitant beaucoup mieux les caches (très visible sur les petites tailles de fichiers) alors qu'avec le 2.6.31 les résultats sont très faibles pour le disque "classique" sans aucune explication évidente. 

Quadcore :

Là c'est spécial, le SSD est très lent (!), alors que le SATA se comporte beaucoup mieux. Aucune explication évidente à part les contrôleurs disques et les drivers associés ou encore ce disque SSD pas bon en écriture ? 

Conclusion : sur ce test une des deux machines donne un résultat contraire à la logique et franchement surprenant sans explication évidente. A ce sujet voir l'article sur le TRIM.

Résultats en écriture "random", tous les résultats sont donnés pour les deux versions de noyau choisies 2.6.31 et 2.6.33. 
Dualcore :

Les résultats sont "logiques" et montrent un net avantage au SSD qui tire avantage de sa structure "statique". Les caches permettent qu disque "classique" de faire illusion sur les fichiers de petite taille ( < taille du cache). 

Quadcore :

Même résultats "illogiques", le disque "classique" l'emporte sur le SSD dans la plupart des configurations sans aucune explication évidente. 

Conclusion : sur le dualcore le SSD l'emporte de manière évidente, sur le quadcore il se passe quelque chose de très défavorable au SSD et les résultats du disque "classique" ne sont même pas bons. Une vérification s'impose au niveau du paramétrage de chaque système. Voir à ce sujet l'article sur le TRIM.

Ayant passé quelques heures à rechercher les "bons" paramètres pour gnuplot je ne résiste pas et vous livre le script qui permet de réaliser ces beaux dessins :

set terminal png size 600,800 
# Paramètres 
# X = COL 1 (taille fichier) 
set xrange [4096:1200000] 
set logscale x 
set xtics ("4M" 4096,"8M" 8192,"16M" 16384,"32M" 32768,"64M" 65536,"128M" 131072,"256M" 262144,"512M" 524288,"1G" 1048576," " 1200000) 

# Y = COL 2 (taille record) 
set yrange [16:512]; 
set logscale y 
set ytics  (16,32,64,128,256,512) 

# Z = valeur (affichée en "vertical") 
set zrange [1000:45000] 
set ztics 4500 

set grid xtics ytics ztics 

set title "Graphe pour write  QUAD 2.6.33" 

# rotation de l'image 
# Paramètres  1 = haut bas, 2 = rotation "verticale", 3 = scale x, 4 = scale Y 
set view 82,30,1,1 
show view; 

# paramètres des graphes 
# pas toujours beau de cacher 
# set hidden3d 

set ticslevel 0 

# Dessin de la courbe 
set output './GR3D_write.png' 

# Les valeurs sont 1      2      3 
#                  Horiz  Prof   Vert 
# --> seule la colonne 3 change 

splot './GR3D_SATA.data' using 1:2:3 with linespoints title "Sata" ,\ 
      './GR3D_SSD.data' using 1:2:3 with linespoints title "SSD" 

Les données issues de IOZONE se présentent sous la forme suivante : 
4096      16    5186   16680    14973    16750   43991   19815   17172    35960    16189   271512   637599 
41750  1252212 
8192      16    1434    9323    28470    30851   49824   11009   12213    22726    23055   261390   647544 
1321294  1332670 
16384      16    2342    8505    34228    44150   49955    5517   23756    28867    29089   266250   645243 1329232  1349806 
32768      16    1910    7892    46899    52612   49608    5493   31623    48795    40638   262227   637958 1308162  1318313 
65536      16    1901   15269    57790    59384   50686    5318   38498    38474    45373   262871   636297 1325699  1338611 
131072      16    2056   13492    50604    63858   50527    5627   46133    40310    48394   259907   629282 
1303419  1313993 
262144      16    2109   15342    56704    68718   48837    6939   49306    30937    49158   261380   648884 1312499  1319461 
524288      16    2210   14232    67886    68860   49550    6104   49283    48960    49798   249599   626107  423431  1334324 

Pour chaque longueur d'enregistrement. L'association du script et des données (pour toutes les longueurs d'enregistrement donne les jolis dessins suivants:

• En "horizontal" la taille de fichier (4M à 1024M)
• En "profondeur" la taille d'enregistrement (16 à 512)
• En "hauteur" la valeur de la donnée en KO/seconde

C'est y pas beau ?

 
 

Le premier test est juste destiné à apprendre le fonctionnement basique des outils liés à BTRFS il a été executé sur des volumes LVM créés pour l'occasion avant de passer au travail sur des partitions physiques. 
Mais, ATTENTION, la version des outils n'est (sur Debian unstable) encore que "0.19+20120328-1". Cela bouge mais la version "stable" 1.0 est peut-être encore assez loin. 
Pour tester BTRFS il faut un noyau dont le support BTRFS est activé ! Si, comme c'est probable le support BTRFS est compilé en module un simple : 
modprobe btrfs 
devrait vous renseigner : 
FATAL: Module btrfs.ko not found. 
ou bien meilleur aucun message et un code retour 0. 
Ce support devrait être actif pour les noyaux récents de la plupart des distributions, sinon compilez le vous même et installez le. Les tests sont réalisés avec un noyau très récent (3.4.4) afin de bénéficier des dernières corrections. 
Ensuite il faut charger les outils BTRFS pour disposer, entre autres, de mkfs.btrfs. Sur Debian le paquet se nomme "btrfs-tools" sans autre complication et s'installe rapidement. 
Pour ce premier test j'ai créé deux "disques" LVM de 20G nommés : 
VOL_EXT4 et VOL_BTRFS. Le premier sera formaté classiquement en EXT4, le secon en BTRFS. 
La commande "mkfs.btrfs" assure le formatage et la labellisation, ici : 
date ; mkfs -t btrfs -L DISK_BTRFS /dev/mapper/TALE-VOL_BTRFS ; date 
vendredi 4 mai 2012, 19:55:30 (UTC+0200) 

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL 
WARNING! - see http://btrfs.wiki.kernel.org before using 

fs created label DISK_BTRFS on /dev/mapper/TALE-VOL_BTRFS 
    nodesize 4096 leafsize 4096 sectorsize 4096 size 20.00GB 
Btrfs Btrfs v0.19 
vendredi 4 mai 2012, 19:55:30 (UTC+0200) 

Le résultat est quasi instantané ! 

En EXT4 : 
date; mkfs -t ext4 /dev/mapper/TALE-VOL_EXT4 ; date 
vendredi 4 mai 2012, 19:56:52 (UTC+0200) 
mke2fs 1.42.2 (9-Apr-2012) 
Filesystem label= 
OS type: Linux 
Block size=4096 (log=2) 
Fragment size=4096 (log=2) 
Stride=0 blocks, Stripe width=0 blocks 
1310720 inodes, 5242880 blocks 
262144 blocks (5.00%) reserved for the super user 
First data block=0 
Maximum filesystem blocks=4294967296 
160 block groups 
32768 blocks per group, 32768 fragments per group 
8192 inodes per group 
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000 
Allocating group tables: done                             
Writing inode tables: done                             
Creating journal (32768 blocks): done 
Writing superblocks and filesystem accounting information: done    
vendredi 4 mai 2012, 19:56:54 (UTC+0200) 

Deux secondes pour 20G, donc plus de trois minutes pour un disque de 2To. On monte ensuite les deux partitions et on vérifie : 
df | grep mnt 
/dev/mapper/TALE-VOL_EXT4    20907056    440692  19417788   3% /mnt/VOL_EXT4 
/dev/mapper/TALE-VOL_BTRFS   20971520       120  18845632   1% /mnt/VOL_BTRFS 
Tiens ETX4 consomme 3% ?

Tests "dd" en écriture, fichier de 8Go :  
Pour EXT4 wait 37 .. 75%    BO # 65000 .. 136000 (chiffres de "vmstat")  
256000+0 records in 
256000+0 records out 
8388608000 bytes (8,4 GB) copied, 63,0721 s, 133 MB/s

Pour BTRFS wait 29.. 55%          BO # 68000 .. 180000  
256000+0 records in 
256000+0 records out 
8388608000 bytes (8,4 GB) copied, 60,2699 s, 139 MB/s

Tests "dd" en écriture, fichier de 16Go : 

Pour EXT4 wait 37 .. 75% output # 65000 .. 136000 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 136,869 s, 123 MB/s 

Pour BTRFS wait 29.. 55% output # 68000 .. 190000 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 123,338 s, 136 MB/s 

La vitesse du BTRFS n'est que très peu supérieure mais les "wait_states" sont inférieurs (mesuré avec vmstat) mais reste plus constante pour les fichiers de 8G et 16G. 

Tests "dd" en lecture, fichier de 16Go : 

EXT4 : 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 125,661 s, 134 MB/s 

BTRFS : 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 119,848 s, 140 MB/s 

Léger avantage à BTRFS.

Aucune commande complexe n'a été utilisée ici, la seule différence est la pose du label de FS par "mkfs.btrf" qui simplifie un peu les commandes. 
Les tests précédents ont étés réalisés avec un noyau "xenifié", ci-dessous le même test sur la même version de noyau (3.3.4) en mode "normal" : 
Test "dd" en lecture fichier 16Go :

EXT4 : 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 108,485 s, 155 MB/s 
BTRFS : 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 99,3723 s, 169 MB/s 

Les résultats sont meilleurs laissant toujours un léger avantage à BTRFS. 
J'ai prévu de présenter plus loin quelques possibilités attrayantes et les outils qui permettent d'y arriver. C'est tout pour aujourd'hui ... à la prochaine.

Après plusieurs mois d'usage BTRFS se comporte très bien. 
J'ai eu un plantage (corruption) tout à fait au début mais les outils de réparation du FS ont fonctionné correctement bien que m'ayant rappelé avant lancement qu'ils n'etaient que des versions "beta" encore incomplètes.

Depuis je suis passé à des versions de noyau très récentes (3.5 et 3.6 maintenant) et je n'ai plus souffert d'un seul ennui. Je pense que le support BTRFS a été amené à maturité dans les dernières versions de noyau et qu'il est parfaitement envisageable de l'utiliser. J'ai d'ailleurs transféré tous mes répertoires personnels sur une partition RAID (/dev/mdx) formatée en BTRFS.

Au vu des sauvegardes que j'effectue régulièrement je n'ai pas vraiment testé les "snapshots" de BTRFS. 
Note 2016 : pas d'ennuis avec les noyaux de la série 4.x.
Note 2024 : BTRFS est toujours là et fonctionne normalement

Ce dernier test doit permettre de mesurer toute la puissance et la souplesse de BTRFS car il va ici jouer deux rôles : 
- gestion du RAID 
- gestion du File system 
permettant ainsi de n'utiliser qu'un outil au lieu des deux habituels (Device Mapper ou LVM pour le RAID, Gestionnaire de FS tel EXT3, EXT4 ...). Pour améliorer la fiabilité (et la rapidité ?) les deux disques sont sur deux contrôleurs différents. On utilisera le parametre "odirect" de "dd" pour limiter l'influence de la mémoire. 
D'abord "casser" le RAID actuel, c'est super simple ... 

mdadm -S /dev/md0            # stopper le device 
mdadm --zero-superblock /dev/sde1    # effacer les traces 
mdadm --zero-superblock /dev/sdd1    # sur les deux disques 

Après cette petite opération il est de bon ton de redémarrer le système pour assurer une bonne reconnaissance des changements. effectués.
Sitôt dit, sitôt fait et on enchaîne sur la création de notre RAID1 BTRFS : 
mkfs.btrfs -m raid1 -d raid1 -L BTRFS /dev/sdc1 /dev/sdd1 
WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL 
WARNING! - see http://btrfs.wiki.kernel.org before using 
adding device /dev/sdd1 id 2 
fs created label BTRFS on /dev/sdc1 
    nodesize 4096 leafsize 4096 sectorsize 4096 size 800.00GB 
Btrfs Btrfs v0.19 
On monte ce nouveau FS : 
mount LABEL=BTRFS /mnt/DISK1omount LABEL=BTRFS /mnt/DISK1 
et on vérifie : 
df -k | grep mnt 
/dev/sdc1                   838860800      312 803151616   1% /mnt/DISK1 

Seul le premier disque est visible et le FS est bien noté 800GB. 
Un petit test "dd" en écriture : 
dd if=/dev/zero of=/mnt/DISK1/test bs=32K count=1536000 conv=fsync oflag=direct 
1536000+0 records in 
1536000+0 records out 
50331648000 bytes (50 GB) copied, 1001,96 s, 50,2 MB/s 

Pendant ce temps les deux disques sont actifs, chacun sur leur contrôleur : 
21:06:33 sdd   1577,00      0,00 100928,00     64,00      0,44      0,28      0,28     43,60 
21:06:33 sde   1578,00      0,00 100992,00     64,00      0,75      0,48      0,47     74,80 
Average: sdd   1577,00      0,00 100928,00     64,00      0,44      0,28      0,28     43,60 
Average: sde   1578,00      0,00 100992,00     64,00      0,75      0,48      0,47     74,80 

Pour corser un peu la comparaison je vais profiter de la partition "2" toujours en RAID-1 (Device Manager) pour la formater en BTRFS et comparer ainsi le RAID-1 BTRFS "pur" et le RAID-1 "DM" + BTRFS. La partition 2 étant un peu moins rapide du fait de sa position DM + BTRFS part avec un petit handicap (#5%). 
Les résultats bruts : 
RAID-1 BTRFS : 
1536000+0 records in 
1536000+0 records out 
50331648000 bytes (50 GB) copied, 966,6 s, 52,1 MB/s 
DM + BTRFS : 
1536000+0 records in 
1536000+0 records out 
50331648000 bytes (50 GB) copied, 993,912 s, 50,6 MB/s 
Au vu des chiffres on peut considérer qu'il y a égalité. 
Passons à la lecture et afin de vérifier si les deux disques sont bien utilisés on va tester deux configurations : 
DD avec l'option "idirect" 
DD sans l'option "idirect" 
RAID-1 BTRFS avec "idirect" : 
dd if=/mnt/DISK1/test of=/dev/null bs=32K conv=fsync iflag=direct 
1536000+0 enregistrements lus 
1536000+0 enregistrements écrits 
50331648000 octets (50 GB) copiés, 489,408 s, 103 MB/s 

Sans "idirect" : 
dd if=/mnt/DISK1/test of=/dev/null bs=32K conv=fsync 
dd: fsync a échoué pour « /dev/null »: Argument invalide 
1536000+0 enregistrements lus 
1536000+0 enregistrements écrits 
50331648000 octets (50 GB) copiés, 430,43 s, 117 MB/s 

DM + BTRFS avec "idirect" : 
dd if=/mnt/DISK2/test of=/dev/null bs=32K conv=fsync iflag=direct 
1536000+0 enregistrements lus 
1536000+0 enregistrements écrits 
50331648000 octets (50 GB) copiés, 508,961 s, 98,9 MB/s 

Sans idirect : 
dd if=/mnt/DISK2/test of=/dev/null bs=32K conv=fsync 
1536000+0 enregistrements lus 
1536000+0 enregistrements écrits 
50331648000 octets (50 GB) copiés, 380,004 s, 132 MB/s 

Avec l'utilisation de "idirect" les deux possibilités sont à peu près à égalité. Par contre sans ce flag le couple "DM" + BTRFS est très loin devant ... 
On refait le test en notant l'activité des différents disques sur une vingtaine de secondes : 
RAID1 BTRFS 
sar -pd 2 10 | egrep 'sdd|sde' | grep 'Average' 
Average: sde    309,50 213753,60      0,00    690,64      9,64     31,16      3,12     96,68 
Average: sdd      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00 

DM + BTRFS 
Average: sde    187,60 140957,60      0,00    751,37      5,77     30,60      3,80     71,28 
Average: sdd    163,10 109883,20      0,00    673,72      4,26     26,19      3,96     64,56 

On remarque tout de suite que BTRFS n'utilise qu'un disque au cours de ce test alors que DM en utilise deux ce qui explique probablement la meilleure vitesse obtenue. 
Remarque : lors d'un deuxième test BTRFS a utilisé l'autre disque il est donc probable que sur plusieurs IO simultanées il est capable de se servir des deux disques. 
On vérifie avec deux "dd" en parallèle : 
Average: sde    937,40 207295,20      0,00    221,14     28,18     29,98      1,06     99,60 
Average: sdd      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00 
Et bien non il se sert d'un seul disque ? Et avec deux fichiers différents que va-t-il se passer ? 
On copie d'abord une partie de notre fichier de 50G : 
RAID1 BTRFS 
dd if=test_UN of=test_DX bs=32K count=512000 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 376,779 s, 44,5 MB/s 
Pendant la copie un seul disque est utilisé en lecture et bien sûr les deux en écriture. 
La vitesse est sensiblement moindre que lors des tests d'écriture seule 44,5 contre 52,1. 

DM + BTRFS 
dd if=test_UN of=test_DX bs=32K count=512000 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 339,194 s, 49,5 MB/s 
Presque la vitesse en écriture seule 49,5 contre 50,6 ! Pendant la copie les deux disques sont utilisés en lecture et en écriture. 
Le test avec deux fichiers 
RAID1 BTRFS : 
Un seul des deux disques est utilisé et le contrôleur est à 100%, le temps de WAIT est élevé (30 à 45%) le CPU utilisé est de l'ordre de 10%  : 
Average: sde    202,70 204479,60      0,00   1008,78     23,49    116,10      4,93    100,00 
Average: sdd      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00 
Fichier 1 ; 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 319,734 s, 52,5 MB/s 
Fichier 2 : 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 260,957 s, 64,3 MB/s 
Soit un total d'environ 117Mo/seconde parfaitement égal au test précédent. 
DM BTFRS 
Les deux disques sont utilisés et les deux contrôleurs à 100%, le temps de WAIT est très élevé (40 à 60%), le cpu utilisé varie de 14 à 28% : 
Average: sde    227,85 218987,20      0,00    961,10     13,08     57,72      4,39    100,00 
Average: sdd    210,60 215552,00      0,00   1023,51     11,94     56,74      4,74     99,92 
Fichier 1 : 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 99,329 s, 169 MB/s 
Fichier 2 : 
512000+0 records in 
512000+0 records out 
16777216000 bytes (17 GB) copied, 155,029 s, 108 MB/s 

Soit un maximum de plus de 270 Mo/seconde ! J'ai refait le test en notant les vitesses moyennes de chaque disque (je rappelle que si les disques sont identiques ce n'est pas le cas des contrôleurs) : 
Average: sde    214,20 219289,60      0,00   1023,76     11,50     53,70      4,66     99,78 
Average: sdd    191,00 165808,40      0,00    868,11      9,27     48,44      5,02     95,92 
Un des disques va nettement plus vite ! Lors de ce second essai j'ai obtenu 150 et 112Mo/seconde soit environ 260Mo/seconde, ce qui est en phase avec le premier essai. 

En bref DM + BTRFS ça a l'air de déménager. Ce petit problème réglé je vais remettre la partition 1 en mode "DM". 
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdd1 /dev/sde1 
On reboote par précaution ... et on lance 
mkfs -t btrfs -L BTRFS_1 /dev/md0 
WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL 
WARNING! - see http://btrfs.wiki.kernel.org before using 

fs created label BTRFS_1 on /dev/md0 
    nodesize 4096 leafsize 4096 sectorsize 4096 size 399.87GB 
Btrfs Btrfs v0.19 
Et la synchronisation du raid commence : 
md0 : active raid1 sdd1[0] sde1[1] 
      419299136 blocks super 1.2 [2/2] [UU] 
      [>....................]  resync =  0.1% (515264/419299136) finish=67.7min speed=103052K/sec 
Ces nouveaux disques de 2To semblent nettement plus rapides que les "anciens" disques de 750 Go (2 and déjà) déja présents dans la machine. 
Ne pas oublier ensuite de positionner ce nouveau "raid" dans le fichier "/etc/..../mdadm.conf", 
mdadm --examine --scan 
est votre ami. 
Il est toutefois à noter que j'ai eu quelques plantages système, crash complets sans possibilité de reprendre la main ou "ooops" déclenchant une violation de protection mémoire de "dd" et un crash lors de l'utilisation de "cp -dpR" pour recopier une arborescence complète.

Ces plantages ont eu lieu avec des noyaux < 3.3. Avec un noyau 3.3.5 les plantages ont été moins nombreux, j'ai depuis refait quelques tests avec un noyau 3.4-rc7 pendant lesquels je n'ai noté aucun ennui, les "cp -dpR" ont parfaitement fonctionné malgré les plus de 80Go à recopier (#500 000 répertoires et plus de 2 000 000 fichiers). 
J'ai mis pour le moment mon répertoire personnel (que je sauvegarde souvent) sur une partition en RAID1 DM+BTRFS. Les résultats sont pour le moment excellents, l'affichage de photos me semble beaucoup plus rapide qu'avant malgré les 15 à 19Mo de chaque photo.

Un autre test fait sur mon répertoire HOME (maintenant en BTRFS) recopié pour sauvegarde dans une baie externe : 
Environ 16 Go avec  #5700 répertoires et #57000 fichiers (Pas mal de fichiers photo RAW et JPG de 10 à 15Mo chacun) en un peu moins de 4 minutes soit une vitesse moyenne de # 66Mo/seconde comprenant donc lecture sur BTRFS et écriture sur une partition LVM de la baie. 
Ainsi la copie de sauvegarde devient (presque) un plaisir.

Baie 4 disques ESata DATATALE RCM4QJ

Ayant eu besoin de sauvegarder des documents, des films, des photos, tous objets très volumineux j'ai cherché un système externe de très grande capacité. 
Note 2022 : cette unité fonctionne toujours parfaitement, évidement avec Linux ..., je m'en sert une fois par mois pour faire des sauvegardes. 
Un peu par hasard je suis tombé sur une firme Taïwanaise qui commercialisait un système qui m'a semblé intéressant. La boite est munie de connexions variées (USB2, Firewire 400 et 800 et ESata), c'est bien entendu la connexion ESata qui m'a le plus intéressé car elle est en principe un gage de vitesse. 
Ce boîtier permet en outre d'utiliser différents types de RAID avec ou sans disque de secours et supporte tous les types de disques, même les derniers disques de 3Téra. On peut donc créer un RAID5 de 9 Téras avec 4 disques de 3To. N'ayant que des disques de 2To je serais limité à 6To en RAID5 ou 4To en RAID10. 
Le boîtier modèle RCM4QJ (la version USB/Firewire 400/800, ESata) peut être trouvé chez quelques revendeurs européens ou sur Amazon pour environ 250 Euros et parfois moins ...Lien vers le site du constructeur. 
Ayant réussi à m'en procurer une unité depuis Taïwan je vous présente les premiers tests réalisés. 
Attention à la "qualité" des disques, certains disques (entre autre les disques "green") ne sont pas adaptés à un usage "RAID", voir la mise en garde du constructeur (lien cassé!) .  
J'ai ici utilisé des disques de 2To de marque Hitachi, un peu plus chers que les disques "verts", mais qui fonctionnent sans problème. 
J'ai aussi eu au début quelques problèmes de reconnaissance de l'unité lors du boot et des messages : 
"link is slow to respond, please be patient" peuvent apparaître. 
En effet l'unité est un peu "paresseuse" et le contrôleur "Jmicron" de ma carte mère était configuré en mode "AHCI", en principe conseillé. J'ai depuis changé de carte mère et de processeur et, bien sûr, de version du noyau (actuellement 4.7.1) et cela fonctionne toujours (Août 2016).

Avec cette configuration AHCI la reconnaissance était un peu aléatoire sans modification de quelques constantes du noyau (ATA_WAIT_AFTER_RESET, ATA_TMOUT_FF_WAIT, ATA_TMOUT_FF_WAIT_LONG) avec le contrôleur ESATA de ma carte mère (puce JMicron) pour le détail des manipulations de modification sur le noyau (c'est un bien grand mot) voir l'article spécifique. 

Autre particularité "gparted" ne reconnaît pas correctement le format des partitions et les considère toujours comme "unallocated" bien que celles-ci se montent sans difficulté ! Après usage il est préférable de n'utiliser qu'une partition et de la gérer avec LVM car 6Téra (RAID5) en une seule partition c'est dur à gérer ! Voir le "HOW TO" pour l'utilisation de LVM.  
J'ai préparé, à part, un document sur l'aspect "physique" de l'engin avec quelques belles images. L'engin est certifié compatible Windows et Mac (une version avec interface Thunderbolt et USB3 est en préparation) je l'ai d'abord monté (en USB2) sur un portable sous Windows afin de pouvoir utiliser le logiciel fourni, versions Windows et Mac. Logiciel installé sans problèmes et j'ai configuré les 4 disques présents (4 * 2 Téra) en RAID 10 ce qui doit donner outre 4 Téra, vitesse (disques en série) et securité (2 groupes en miroir). J'espère pouvoir le tester avec un MAC bientôt. Dès la fin de cette opération j'ai tenté le montage en ESata sur une machine Linux ... et l'opération s'est déroulée sans problèmes, Linux a reconnu la baie dès la mise sous tension et a bien reconnu le zinzin -Kernel Debian 3.1.5) : 
[66721.241068] scsi 6:0:0:0: Direct-Access     ATA      SMART   RAID 10  0958 PQ: 0 ANSI: 5 
[66721.241527] sd 6:0:0:0: Attached scsi generic sg4 type 0 
[66721.241552] sd 6:0:0:0: [sde] 7813857280 512-byte logical blocks: (4.00 TB/3.63 TiB) 
[66721.241774] sd 6:0:0:0: [sde] Write Protect is off 
[66721.241786] sd 6:0:0:0: [sde] Mode Sense: 00 3a 00 00 
[66721.241867] sd 6:0:0:0: [sde] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA 

Au vu de la taille de l'unité présentée "fdisk" s'est un peu affolé : 
fdisk /dev/sdg 
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel 
Building a new DOS disklabel with disk identifier 0x7945aefe. 
Changes will remain in memory only, until you decide to write them. 
After that, of course, the previous content won't be recoverable. 
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite) 
WARNING: The size of this disk is 4.0 TB (4000694927360 bytes). 
DOS partition table format can not be used on drives for volumes 
larger than (2199023255040 bytes) for 512-byte sectors. Use parted(1) and GUID 
partition table format (GPT). 
Il vaut donc mieux utiliser "gparted" pour initialiser le disque en "GPT" et le formater en deux partitions EXT3. Après cette petite manip qui laisse le temps d'aller boire un café : 
 
 

 

on obtient ensuite le résultat suivant : 

 

 

 

 

 

 

 

Le montage des deux partitions est ensuite possible et les tests peuvent commencer, d'abord des tests simples pour se donner une idée rapide. 
Un premier test en écriture avec "dd" : 

cd /DATATALE_1 
dd if=/dev/zero of=./toto bs=4096 count=4096000 
4096000+0 enregistrements lus 
4096000+0 enregistrements écrits 
16777216000 octets (17 GB) copiés, 295,005 s, 56,9 MB/s 

Un peu moins de 60Mo/seconde c'est déjà pas mal pour un disque externe. 
Deuxième petit test, plus réel, recopier un ensemble de répertoires comprenant environ 2500 photos réparties dans 28 sous-répertoires pour un total de 21,6Go : la copie est effectuée en un peu plus de 6 minutes soit environ 57Mo/seconde. 

Remarque : 
Après ces tests l'unité ne chauffe pas et reste parfaitement silencieuse, le boîtier en aluminium semble parfaitement remplir son rôle. Bientôt une analyse plus poussée de ce bel engin. 

Voir les tests plus complets sur EXT3 en RAID10.  Et sur EXT4 en RAID5 

Les tests en Ext4 sont en cours .... voici les premiers résultats sur une partition unique de 4To 
Tests EXT4 en écriture : 
dd if=/dev/zero of=./toto bs=4096 count=4096000 
4096000+0 records in 
4096000+0 records out 
16777216000 bytes (17 GB) copied, 232,184 s, 72,3 MB/s 

Même test avec un transfert par blocs de 16K au lieu de 4K : 
dd if=/dev/zero of=./toto bs=16535 count=1024000 
1024000+0 records in 
1024000+0 records out 
16931840000 bytes (17 GB) copied, 218,376 s, 77,5 MB/s 

On approche les 80Mo/seconde ... 

Test rapide EXT4 en lecture : 
dd if=./toto of=/dev/null 
33070000+0 records in 
33070000+0 records out 
16931840000 bytes (17 GB) copied, 162,256 s, 104 MB/s 

Les 100Mo/seconde sont dépassés ! 

Copie de 15Go dans 33 répertoires et #1800 fichiers durée 8 minutes soit #32Mo/seconde. 

Pour finir une vue de cette petite bête installée sur un boîtier moyenne tour en aluminium lui aussi. 
 

Le boîtier vide est très léger, aluminium oblige et de dimensions réduites (l = 14,H = 21,5, P = 21).  L'aspect aluminium est très "propre".  Tout peut être commandé à l'aide des 4 boutons et de l'écran d'affichage.

La sécurité des données. 
Le meilleur moyen pour assurer la pérennité de ses données est d'en assurer une sauvegarde périodique. 
Nos machines modernes ont de gros disques où nous stockons des quantités de données qui peuvent vite augmenter.. 
Les photos font aujourd'hui chacune largement plus de 10Mo pour un reflex de qualité; ou même un téléphone moderne et si vous conservez comme moi les images "RAW" on dépasse les 35Mo par photo. Les films de caméra sont encore plus volumineux et le tout finit par représenter des quantités de données conséquentes auxquelles on tient particulièrement, comment accepter de perdre des documents auxquels on tient particulièrement . 
La valeur (au moins sentimentale) de des données est importante et je ne me vois pas annoncer : tiens ! J'ai perdu les photos et les films du petit dernier ... 
La sauvegarde est donc le seul moyen de s'affranchir (au moins en limitant les dégâts à la perte d'une courte période) est donc la duplication sur un autre support. 
Mais les disques externes USB ne sont pas forcément très fiables et ne sont pas donnés bien que les prix aient là aussi bien baissé. Pour répondre à ce besoin les entreprises utilisent des sauvegardes sur bande magnétique, une bande moderne peut dépasser le Téra-Octet. Mais pour un amateur les lecteurs de bande sont chers (plus chers parfois que la machine que vous utilisez) , encombrants, bruyants et les bandes de grande capacité sont fort onéreuses, un petit parc de bandes est un investissement.

J'ai découvert sur le site d'un revendeur bien connu des petits boîtiers qui permettent d'enficher un disque SATA standard et de le connecter ainsi en USB ou en ESata sur une machine.  Ce type de boîtier se trouve pour 20 à 30 Euros, les disques SATA standards sont par ailleurs moins chers qu'une cartouche de bande magnétique ! Pour quère plus de 40 Euros vous pouvez trouver des disques de 500Go et pour moins de 65 Euros vous atteignez le Téra. Il n'est pas ici nécessaire d'avoir le "nec plus ultra" des disques, le 7200 tours est superflu !.  On peut donc changer facilement de disque et se constituer des archives sécurisées au maximum en mettant un disque dans un autre lieu géographique comme on le fait dans le milieu professionnel pour les cartouches de sauvegarde.  La capacité atteinte permet de sauvegarder facilement l'intégralité d'une machine et peut permettre une sauvegarde adaptés à des artisans ou même à de petites PME pour un investissement très faible.

La procédure de sauvegarde est simple :

• Brancher le zinzin dans le port ESata (ou USB),
• Brancher le boîtier d'alim,
• Enquiller votre disque (2,5 ou 3,5 pouces),
• Mettre le courant en appuyant sur le bouton (original non), le bas de mon boîtier s'illumine en violet comme sur la photo,
• Attendez le montage du disque (!) ou montez le "à la main"
• Pour le premier montage songer à formater le disque, j'ai mis le mien en EXT4, tiens c'est mon premier EXT4.
• Effectuez votre sauvegarde (simple copie) tranquillement sur un engin rapide : 
  Plus de 17000 fichiers (beaucoup de photos) représentant environ 60Go de données sont sauvegardés en 50 minutes soit environ 1,2Go par minute. Ces fichiers étant stockés sur un "partage" Windows accédé depuis une machine Linux (la seule récente avec une prise ESata) qui a effectué la sauvegarde.

Une fois la sauvegarde effectuée, on "umounte" le disque (soyez propres et ne jouez pas avec votre santé ! ) puis on enlève le disque (comme on doit procéder sagement pour une clé USB) et on le range dans un endroit sûr (dans votre coffre à la banque ?) ou dans un autre lieu, ainsi même dans le cas d'un sinistre important (inondation ... crash d'avion ...) vous conserverez vos précieuses données. 
La procédure serait identique sur une machine Windows ou sur un Mac. 
Je vais préparer de jolis graphiques comme ceux présentés dans les articles sur les SSD. 
Toutes les machines sont enfin OK et j'ai pu faire les mesures de vitesse par rapport à un disque SATA classique. En fait le SATA n'est pas tout à fait classique puisque'il s'agit de deux disques en RAID logiciel. Mais totes les mesures que j'ai pu faire n'indiquent pas (ou peu) de différence par rapport à un disque SATA géré de manière normale. 
Voici donc les deux graphiques pour lecture et écriture standard :

Lecture	Ecriture

La lecture sur le disque est excellente et présente une courbe très régulière augmentant classiquement en fonction de la taille des enregistrements, la vitesse atteinte est assez impressionante (quasiment le double de celle du disque "classique"). 
Pour l'écriture le disque "classique" reprend l'avantage bien que sa courbe présente de fortes irrégularités pour les grands enregistrements sur des petits fichiers. C'est probablement un effet du cache mémoire. Le disque ESATA présente une courbe très régulière où l'on voit que la vitesse est très faible pour de petite enregistrements et croît très rapidement avec la longueur des enregistrements. 
Pour mémoire voici les mêmes graphiques comparant SATA et SSD :

Lecture	Ecriture

That's all folks

Note Juin 2019 : ce beau matériel est tombé en panne (électronique), comme il est ancien on n'en trouve plus mais il paraît que l'on peut reprendre les disques sous Linux sans problème.

Note Novembre 2023 : la machine supportant ces disques depuis 2019 est tombée en panne (elle date de 2009) et avant de la "refaire" il me fallait une solution pour stocker ces 5 disques et aucune des "boîtes" dont je dispose  n'a l'espace nécessaire à contenir ce paquet, j'ai donc trouvé un boitier externe (toujours ICY BOX) auquel j'ai consacré un article à voir ici.

Cà y est ! J'ai réussi à disposer d'un bel ensemble de stockage pour mettre toutes sortes de choses à l'abri :

• des vandales
• de l'usure
• de la pluie (?)

C'est une belle boite noire fournie par Thecus ( http://www.thecus.com ) qui peut contenir jusqu'à 5 disques et permet diverses fantaisies de configurations RAID. 
Elle est équipée de :

• 5 baies amovibles qui ferment à clef
• 2 interfaces réseau 1Gigabit
• quelques voyants
• un processeur Celeron M (pour consommer moins)
• Environ 1Go de mémoire
• quelques prises USB
• une prise eSATA

N'ayant pas un besoin évident de "fantaisies" j'ai bêtement configuré la boîte en RAID5 avec les 5 disques d'un coup, avec cinq disques de 1To cela représente un espace de stockage d'environ 4To ! 
Cela devrait suffire pour mettre à l'abri photos, documents et autres archives, il restera encore de la place pour s'amuser. 
L'interface d'administration est accessible par n'importe quel browser, ici Firefox fait merveille : 

La première chose à faire est de changer le mot de passe de l'administrateur ! 
On peut ensuite se balader un peu dans les menus qui semblent assez bien faits. Tiens on peut choisir la langue, je sélectionne donc le français, la traduction est bonne et ne prête pas à confusion. 

On peut même brancher une imprimante et la partager sur le réseau. 
Il est possible de paramétrer l'envoi de mails à une adresse spécifiée, accéder aux journaux du système (Linux), paramétrer les accès réseau (les deux prises Ethernet), modifier leur adresse .... Activer l'accès WebDAV en http et/ou https, activer ou désactiver le service "partage Windows" SMB/CIFS. 
Paramétrer, jour par jour, les heures de démarrage et d'arrêt, gérer une alimentation de sauvegarde. 
 Bref les menus sont très complets. 

La configuration est assez simple et rapide, la constitution du RAID se fait en un écran de paramétrage

• Choix du mode de RAID
• Définition de la taille (en % du total)
• Prise en compte des disques sélectionnés

Clic c'est fini ... et non il faut maintenant que le Raid se construise et avec la taille des disques ce n'est pas juste le temps d'aller boire un café mais plutôt le moment d'aller piquer un bon roupillon  car il y en a pour une douzaine d'heures. 
... 
... 
... 

On peut ensuite dans ce grand bocal créer trois sortes d'espaces :

• des "folders" ( accessibles dans le style partage windows ou en NFS) pour lesquels on définit une taille maximum (quota).
• des cibles iSCSI (jusqu'à 5 cibles) pour lesquelles on définit aussi une taille qui est ici la taille du "LUN".
• des "usbtarget" que je n'ai pas encore expérimentés.

Il y a la possibilité de protéger les accès par :

• aucune protection
• read only
• accès protégé par utilisateur/groupe dans le style Unix avec séparation des accès lecture et écriture 
  On peut même récupérer ces informations depuis un serveur Active Directory dont je ne dispose pas.

Je suis un peu pressé et je crée un premier folder en read/write sans mettre aucun ACL, on verra cela plus tard et je lance le premier test qui consiste à copier tout un groupe de répertoires contenant un gros paquet de photos représentant 25 Gigaoctets pour environ 10600 fichiers. 
Le test est lancé depuis une machine Windows et dure environ 50 minutes : 
50 minutes = 3000 secondes, ce qui représente environ 10Mo par seconde, ce n'est pas merveilleux, mais c'est en fait limité par la bande passante du réseau local à 100Mbits par seconde avec un vieux hub Netgear d'amateur ... 

Visiblement d'autres tests seront nécessaires pour pousser cet engin dans ses retranchements. 

Les tests suivants ont étés réalisés sur une liaison à 1 GB avec une machine Linux, la copie est effectuée bêtement par l'intermédiaire de Nautilus et chronométrée. 
Premier test : 
Recopie depuis le partage Windows des dossiers de photos du test précédent sur une partition locale fraîchement formatée, la copie est réalisée en environ 20 minutes ce qui donne : 
30000 / (20 * 60) = 25 Mo/seconde 

Deuxième test : 
Afin de tester les connexions iSCSI un espace dédié a été crée sur le NS5200 puis accédé et formaté depuis la machine Linux. 
Les commandes suivantes ont été utilisées : 
iscsiadm -m discovery -t sendtargets -p 192.168.3.101 
qui a retourné gentiment : 
192.168.3.101:3260,1 iqn.2009-11.fr.jpp:STO01.iscsi0.vg0.tgtk2000 
J'ai donc ensuite accédé ce nouveau "disque" par : 
TARGET='iqn.2009-11.fr.jpp:STO01.iscsi0.vg0.tgtk2000' 
ADTARG='192.168.3.101' 
iscsiadm -m node -T $TARGET  -p $ADTARG  -l 

Après avoir "fdiské" ce nouveau disque (création d'une seule partition) avec : 
fdisk /dev/disk/by-path/ip-192.168.3.101:3260-iscsi-iqn.2009-11.fr.jpp:STO01.iscsi0.vg0.tgtk2000-lun-0 
puis créé le filesystem : 
mkfs -t ext3  /dev/disk/by-path/ip-192.168.3.101:3260-iscsi-iqn.2009-11.fr.jpp:STO01.iscsi0.vg0.tgtk2000-lun-0-part1 

J'ai enfin pu le monter sur le système pour les tests. 
En utilisant toujours le même bloc de fichier j'ai testé le chargement en écriture dans la partition iSCSI. 
Note : pendant ce test la consommation CPU indiquée par l'interface du NS5200 oscille entre 70 et pllus de 90%, le CPU de l'engin est donc quasiment saturé. 
Résultat final : 
30000  / ( 17 * 60) = 29Mo/seconde 

Troisième test : Recopie d'une partition "locale" de #16Go sur un "disque" iSCSI partitionné en LVM. 
lun. nov. 30 11:34:20 CET 2009 
262144+0 enregistrements lus 
262144+0 enregistrements écrits 
17179869184 octets (17 GB) copiés, 496,765 s, 34,6 MB/s 
lun. nov. 30 11:42:37 CET 2009 

Quatrième test : Recopie d'un fichier de # 16 Go d'un montage NFS sur le NS5200 sur une partition LVM. 
vendredi 4 décembre 2009, 19:20:50 (UTC+0100) 
265472+0 enregistrements lus 
265472+0 enregistrements écrits 
17397972992 octets (17 GB) copiés, 398,503 s, 43,7 MB/s (lecture) 
vendredi 4 décembre 2009, 19:27:28 (UTC+0100)La création de ce même fichier s'était faite à # 26 MB/s (écriture). 

Cinquième test: Recopie d'un fichier de # 16 Go d'un montage NFS sur le NS5200 sur une partition LVM. 
dd if=/MV/COM-MAIL-SYS.img of=/dev/mapper/VOL2-TEMPO bs=65536 
131072+0 enregistrements lus 
131072+0 enregistrements écrits

8589934592 octets (8,6 GB) copiés, 191,646 s, 44,8 MB/s

Sixième test : un peu vicieux recopie d'un fichier de #16Go d'un folder à un autre (NFS)

dd if=XP1.img of=/MV/XP1.img bs=65536 
270336+0 enregistrements lus 
270336+0 enregistrements écrits 
17716740096 octets (18 GB) copiés, 1050,02 s, 16,9 MB/s 

Consommation électrique mesurée avec un "consomètre" trouvé chez Casto:

Rappel les disques sont des Seagate Caviar "green" de 1To

• # 63W Au repos
• # 74W En pleine action (recopie des photos)
• # 17W en mode "veille" (stoppé en attente de démarrage automatique)

La consommation varie peu entre "repos" et "pleine action", le mode veille consomme un peu plus que ma nouvelle machine (#11W) ce qui est un peu bizarre, mais il y a les 5 disques ... 
Le ventilateur est assez bruyant mais maintient la boite quasiment froide, aucune élévation de température n'est  constatée même lors d'utilisation intensive.

Pour des raisons de sécurité et pour offrir un fonctionnement sans incidents aux membres de ma famille qui utilisent ce petit serveur pour centraliser leurs mails et accéder à Internet je me suis équipé d'un onduleur.

Note 2022 : Pour le télétravail j'ai installé un deuxième onduleur (le même) pour alimenter la machine télétravail et le routeur Internet.

Note 2017 : ce matériel est toujours utilisé bien que sur un hardware différent et j'ai changé la batterie après 5 années de fonctionnement. 

Ce matériel est censé :

• protéger le serveur des surtensions
• apporter une meilleure sécurité de fonctionnement
• permettre un arrêt  "en bon ordre" en cas de coupure électrique prolongée
• assurer un redémarrage tranquille lors du retour du courant

Il est prévu pour alimenter le serveur de mails mais aussi le modem ADSL car un serveur sauvegardé mais inaccessible est assez peu utile ! 
La puissance prévue est assez faible :

• moins de 60W pour la machine
• moins de 10W pour le modem

soit une puissance totale inférieure à 70W.

Un logiciel de gestion de mails sous Linux est obligatoire, qui irait confier ses mails secrets a W..... 
Et voilà pour le cahier des charges .... 
J'ai trouvé en promotion chez un fournisseur un onduleur donné pour 650VA et quelques minutes d'autonomie à cette puissance pour environ 90 Euros. Ce matériel est un modèle ELLIPSE ECO 650USB de taille très raisonnable et qui peut être installé verticalement ou horizontalement. 
Le CD de logiciel fourni ne comporte, évidemment, que des logiciels W.... mais le fournisseur dispose sur son site de versions spécifiques Linux pour X86/32 et X86/64 en format DEB et RPM, le pied quoi ! 
Mon petit serveur dispose d'une Debian 6 qui a accepté sans protester l'installation de la version 32bits. 
Il est nécessaire de brancher la bête sur un port USB avant de lancer l'installation du logiciel ou alors il faudra, comme moi, recourir à l'option "-install" du logiciel. 
L'installation est effectuée par "dpkg" directement dans le répertoire : 
/usr/local/Eaton/IntelligentPowerProtector qui contient ensuite : 
-rwxr-xr-x 2 root  root  3551758 Jul 26 18:23 Eaton-IPP 
drwxr-xr-x 3 root  root     4096 Jul 26 01:42 bin 
drwxr-xr-x 5 root  root     4096 Jul 26 01:46 configs 
drwxr-xr-x 2 root  root     4096 Jul 28 00:56 db 
drwxr-xr-x 2 root  root     4096 Jul 25 21:18 desktop 
-rw-r--r-- 1 root  root     1866 Jul 26 18:24 install.log 
le programme principal " Eaton-IPP" est muni d'un "--help" succinct mais suffisant pour nous : 
./Eaton-IPP --help 
Eaton Intelligent Power Protector v1.10.045 
Usage: /usr/local/Eaton/IntelligentPowerProtector/./Eaton-IPP [COMMAND] [OPTION]... 
Available commands: 
    -install:    launches the installation process (default). 
            Use graphic installer if able. 
Available options: 
    -debug:        displays debugging information on the console. 
    -dir:        specifies installation folder. 
    -silent:    install the application silently. 
            Installation folder can be provided with -dir 

Par ailleurs un script de démarrage est installé dans /etc/init.d avec tous les liens "qui vont bien" dans les différents répertoires /etc/rc?.d : 
./init.d/Eaton-IPP 
./rc0.d/K01Eaton-IPP 
./rc0.d/K20Eaton-IPP 
./rc1.d/K01Eaton-IPP 
./rc1.d/K20Eaton-IPP 
./rc2.d/S19Eaton-IPP 
./rc2.d/S20Eaton-IPP 
./rc3.d/S19Eaton-IPP 
./rc3.d/S20Eaton-IPP 
./rc5.d/S19Eaton-IPP 
./rc5.d/S20Eaton-IPP 
./rc6.d/K01Eaton-IPP 
./rc6.d/K20Eaton-IPP 
La panoplie se complète de lignes de menus (Gnome pour moi) permettant de lancer une interface de gestion "Web" dont il faudra, bien sûr, changer immédiatement les caractéristiques de l'utilisateur d'administration, le traditionnel admin/admin ! 
Cette interface permet aussi de déclencher différentes actions sur les évènements électriques y compris l'envoi de mails et bien sûr l'arrêt de la machine secourue avant l'épuisement de la batterie. 
Elle permet aussi de surveiller l'onduleur et d'afficher des graphiques d'utilisation des ressources sur quelques heures ou quelques jours et on peut exporter le log à des fins de suivi. 
C'est assez complet et permet même d'administrer plusieurs onduleurs, avis aux amateurs (la firme fournit aussi des matériels beaucoup plus professionnels). 

Un essai, en débranchant la prise, m'a montré que le tout fonctionnait très bien et donnait plus de 30 minutes d'autonomie à ma petite machine avant le déclenchement de l'arrêt du système par la commande programmée dans l'interface : "/sbin/init 0". 
Lors du retour du courant le système ne redémarre pas immédiatement mais attend pendant une certaine durée que la tension soit bien stabilisée ! 
En bref cela semble un bon produit : 
- matériel agréable à l'oeil qui semble bien conçu 
- logiciel pour Linux bien pensé et offrant de nombreuses possibilités avec une francisation impeccable.

Au sujet du logiciel j'ai installé la version 1.10 qui fonctionne fort bien, ce soir (31/07) l'interface WEB m'a proposé une version plus récente (1.20) que j'ai récupérée sur leur et installée et patatrac l'onduleur n'est plus reconnu message : "perte de liaison". J'ai ré-installé la version 1.10 et tout est de nouveau OK. 
Les notifications fonctionnent très bien et j'ai reçu ce matin le message suivant :

Alarme depuis Ellipse ECO 650 : 30/07/12 - 08:27:20 - L'onduleur est arrêté 
Alarme depuis Ellipse ECO 650 : 30/07/12 - 08:27:22 - L'onduleur fonctionne 

Un usage de quelques mois montrera la fiabilité de ce système. 
Presque 4 ans après, ce qui prouve que l'onduleur s'est fait oublier par un fonctionnement impeccable !

Après quelques années (on est en 2016) l'onduleur fonctionne toujours, il faudrait que je change la batterie qui semble un peu plus "faible" qu'à ses débuts mais tient encore bien les 5 minutes de délai avant coupure propre du système (shutdown en bon ordre). La machine a évolué vers un CoreI3 série 4, et outre les mails gère un IDS (Suricata) et 3 machines KVM :

• mail : Zimbra sur un Ubuntu LTS 2004 depuis debut 2021.
• Web : apache 2.4.53 sur une Debian 11.3
• Shinken/Grafana sur une Debian 11.3, devenu Shinken/InfluxDB/Grafana au dernier trimestre 2017

Et ça tourne ! 
 

Ma machine principale commençait à donner des signes de faiblesse et était une grosse consommatrice d'énergie. 
Machine d'origine :

• 2 Athlon MP, pas un dual core, mais bien 2 Cpu mono core
• une carte mère MSI pour bi-processeur
• 2 disques SCSI de 36Go à 15000 tours
• 2 disques SATA de 250Go montés en miroir
• 3 gigas de RAM
• carte video AGP
• diverses cartes d'extension : SCSI, réseau
• Boitier tour Antec
• Alimentation Antec de 650W quasiment neuve

La consommation de l'engin était de l'ordre de 200W électriques en pleine action, de 170 en ne faisant rien et 30W en "veille" (machine stoppée mais alimentation non coupée). 
Quelques ennuis :

• Une alim grillée avec perte du disque système
• Des lenteurs au boot s'étant manifestés (boot "à la manivelle" ou à l'aide du CD de secours) j'ai décidé qu'il était temps d'upgrader cette machine dont l'architecture datait de plus de trois ans.

Pour faire un peu plus "vert" j'ai regardé du coté des processeurs peu "énergivores" et j'ai jeté mon dévolu sur un AMD Phenom 950e (Quad core basse consommation à 2,5Ghz). 
Pour la carte mère j'ai longtemps hésité puis jeté mon dévolu sur une carte MSI  790FX-GD70 munie des derniers chipsets AMD  et de :

• deux interfaces réseau 1Gb
• plein de ports USB
• 6 sorties SATA principales
• 2 sorties SATA sur un deuxième contrôleur
• 1 sortie eSATA
• 1 sortie son qui semble très correcte
• 1 sortie ATA pour relire les vieux disques ... pas les 78 tours quand même
• plein de trucs pour économiser l'énergie ? Tout doit être vert maintenant.
• facilités d'overclocking

J'ai décidé de récupérer le plus possible d'éléments de l'ancien système et de passer allègrement en 64 bits. 
Eléments récupérés :

• le boitier, que j'utilise encore en 2022
• l'alimentation (presque neuve !)
• les deux disques SATA contenant toutes mes données personnelles

Auxquels ont été adjoints :

• un disque SSD OCZ vertex de 32 Go pour le système
• 8 gigas de RAM (4 * 2Go)
• la carte mère
• le processeur
• une carte video PCI Express

 Une fois la décision prise il faut se fabriquer une petite procédure de migration afin de prendre le minimum de risques pour :

• se garantir contre la perte des données personnelles
• se garantir contre la perte des paramètres du système

Pour remplir ce mini cahier des charges les opérations à réaliser :

• Sauvegarder les données personnelles importantes sur un disque externe
• Mettre en sureté les deux disques SATA (débranchement/démontage)
• Sauvegarder les répertoires système contenant des paramétrages qui peuvent servir notamment :
  • /etc
  • /var
  • /usr
• tenter de relire les sauvegardes réalisées, on ne sait jamais !

Une fois toutes ces opérations "sécuritaires" réalisées on peut s'attaquer au boulot physique :

• repérage et marquage du cablage reliant boitier et carte mère, vieux cables poussiéreux, atchoum ! (pas H1N1 heureusement)
• démontage propre (!) des disques SCSI, si jamais j'en avais besoin
• démontage propre de la carte vidéo et des cartes d'extension (contrôleur SCSI, contrôleur SATA, carte réseau 1Gb, carte video non réutilisable car AGP).

Après un bon dépoussiérage à l'aspirateur et on peut s'attaquer au remontage :

• montage du processeur et de son radiateur (d'origine) "sur table"
• mise en place de la mémoire, c'est plus facile avec la carte mère "sur table"
• montage de la carte mère dans le boitier
• mise en place du joli cache de la face arrière plein de belles couleurs que l'on ne voit plus ensuite !
• disque SSD (il est tout petit dans son logement pour disques 3,5)
• câblage avec changement des cables de l'alimentation pour les disques SATA, heureusement cette alimentation était livrée avec plusieurs jeux de cables disques aux différents formats (IDE et SATA) et trois sorties séparées "pluggables" sur le boitier pour la stabilité ...
• Mise en place du lecteur/graveur CD/DVD en SATA, le vieux était en IDE !
• Mise en place de la carte video PCI Express
• pas d'autres extensions, tout est compris, son et réseau.

Je garde volontairement le montage des deux disques SATA pour plus tard lorsque le système sera stable, on ne prend pas de risques avec les données personnelles... 

Alors, on y met le feu ? 
Pas tout de suite, une petite révision du câblage pour limiter les dégâts. 
Après le branchement électrique et la mise sous tension, j'appuie sur le bouton de mise en route et tends l'oreille (et l'oeil) pour guetter le démarrage des ventilateurs. 
Horreur, un des ventilateurs du chassis ne démarre pas ! Je coupe et revérifie le câblage --> câble pas enfiché à fond ! . 
Un nouveau petit coup sur le bouton, tout ronronne normalement, aucun voyant rouge clignotant ne s'est allumé, seules quelques belles LED bleues illuminent l'intérieur du boitier, on croirait presque un arbre de Noël et l'écran affiche la configuration du BIOS ... c'est parfait. 

On va pouvoir passer à l'installation "soft" ... au prochain article.

Pour le système comme je suis un fan des distributions Debian la question ne se posait même pas, j'installe donc une Debian sur le beau disque SSD. 
Je n'aime pas mettre tous les oeufs dans le même panier et je prévoit d'utiliser le partitionnement suivant :

• Boot #1Go pour pouvoir mettre en place plusieurs versions et peut-être Xen
• Swap # 1Go par habitude, bien qu'avec 8Go de mémoire le swap devrait être nul !
• Le reste soit environ 30Go pour la partition racine

La carte dispose de deux contrôleurs SATA :

• Le premier avec deux sorties, je les utilise pour le SSD système et le lecteur de CD, Ce contrôleur dispose d'une fonction RAID intégrée que je n'exploiterai pas ici.
• Le deuxième avec six sorties que je garde pour la suite.

Je "brancherais" plus tard le disque contenant mes données personnelles, vive "ln -s ...". 
Comme j'ai lu quelque part que l'installation pouvait poser des problèmes sur les SSD si l'on démarrait "plein pot" je réduis le diviseur dans le Bios de 12,5 à 6. Comme la carte dispose d'interfaces réseau "incorporés" je lance une installation avec le CD "Net Install" promptement téléchargé et gravé sur une autre machine (# 180Mo c'est vite fait). Je démarre et je choisis l'installation "texte" et précise la langue, le clavier ... tout le "hard" semble bien reconnu et la configuration réseau automatique (vive le DHCP) est OK. Je décide de faire une installation minimale de la version "stable" de Debian avant de basculer en "unstable" que j'aime bien utiliser sur une machine personnelle (ne pas le faire sur une machine de production !). Tout se passe bien, le téléchargement par le réseau d'un grand nombre de packages (1172 paquets !) est parfait (environ 30 minutes sur ma liaison), l'installation de déroule sans aucun problème apparent. 
Je décide d'utiliser le tout nouveau "Grub" (1.97 en attendant le 2.0) et non le vieux "lilo" auquel je m'étais bien habitué. Ah, ça reboote ... et le démarrage est ultra rapide, X se lance sans problème à la bonne définition correspondant à celle de mon écran : 1680 x 1050 sans que je n'aie rien fait ! Un gros bon point à toute l'équipe Debian. 
Après quelques tests je décide de passer en "unstable" comme je l'avais prévu. Après quelques modifications dans le fichier "/etc/etc/sources-list" je lance la commande fatidique : aptitude dist-upgrade 
Après quelques temps de réflexion aptitude me propose une première solution qui me semble parfaite, je réponds donc "Oui" et appuie sur la touche "Entrée" ... c'est parti ... il y a plus de 500 Mo à charger, je laisse donc l'opération se dérouler pendant que je vais faire une petite promenade très favorable à une meilleure santé, en plus il fait très beau aujourd'hui ! Je repasse une bonne heure plus tard, tout est fini, même le noyau a été upgradé et le fichier "grub.conf" mis à jour. L'ancien noyau reste bien sûr disponible. 
Je reboote sur le nouveau noyau et tout est OK, sauf l'accès X : plus de souris et plus de clavier ... après un bon moment de réflexion je vais consulter le log de GDM qui me dit ne pas avoir trouvé les drivers clavier et souris ???? 
Je vais voir dans le répertoire "/usr/lib/xorg/modules/input" et c'est exact, les drivers "kbd_drv.so" et "mouse_drv.so" brillent par leur absence ! Je suis bon pour ré-installer les paquets :

• kbd_drv.so
• mouse_drv.so

Aprés ce petit "hic" l'accès est normal et je peux me lancer dans la suite : installer les paquets des logiciels auquel je suis habitué :

• Apache + PHP
• Mysql
• OpenOffice
• Postfix
• Evolution
• ...

On relance "aptitude" avec la liste des logiciels voulus et tout s'installe directement. 
Je sais bien que je n'ai pas pensé à tout et que pendant 3 ans j'avais, petit à petit, ajouté des utilitaires "indispensable", tant pis on les ajoutera à grands coups de "apt-get istall le_logiciel_qui_me_manque". 
Il suffit ensuite de récupérer les "anciens" fichiers de paramétrage depuis la sauvegarde de "/etc" de ces logiciels pour qu'ils fonctionnent exactement comme sur l'ancien système 32bits. 
Il est temps maintenant de reconnecter le miroir contenant mes données personnelles labellé RAIDZZZ. Quelques coups de tournevis pour tout bien fixer et on relance le zinzin. Le disque est là, il me suffit de reconnecter le répertoire "home" présent sur ce disque en lieu et place du /home par un bon : mv /home /home_ori 
ln -s /RAIDZZZ/home /home et modifier le fichier "fstab" pour qu'il reconnaisse le label "RAIDZZZ" dès le boot :  LABEL=RAIDZZZ   /RAIDZZZ  ext3  relatime    1    1 
Un reboot plus tard je fait un login sur mon utilisateur perso et je retrouve toutes mes petites affaires, documents, mails ... parfaitement en place, icônes et applets Gnome compris, comme sur l'ancien bouzin, ça c'est formidable ... Je peux donc maintenant retravailler car cela "pète le feu". Tiens au fait, ai-je remis le multiplicateur à 12.5 ? Un petit tour dans le Bios plus tard je constate que, bluffé par la performance, j'avais complètement oublié de remettre ce truc à la bonne valeur, je travaillai donc à 50% de la vitesse. Vite on remet l'accélérateur "pied au plancher". Ouahhh, là çà décoiffe carrément, l'écran de login X en une quinzaine de secondes après le choix du noyau dans Grub. Il est temps de regarder la consommation de cet engin :

• # 10 W à l'arrêt en veille
• # 105 W en marche sans activité processeurs à 800 Mhz
• # 145 W en recompilant un noyau Linux avec "make -j 6" pour saturer les processeurs

Là c'est nettement moins que l'ancienne machine, ma facture EDF devrait baisser ... Allez j'y retourne pour surfer un peu. Quelques mesures ( zut j'avais oublié d'installer "hdparm" ) :

• Disque SATA en miroir : 
  hdparm -t /dev/md2 
  /dev/md2: 
  Timing buffered disk reads:  220 MB in  3.01 seconds =  73.11 MB/sec
• Le disque SSD : 
  hdparm -t /dev/sda2 
  /dev/sda2: 
  Timing buffered disk reads:  378 MB in  3.00 seconds = 125.95 MB/sec

La vitesse est au rendez-vous. 

Temps de démarrage :

• Temps depuis le choix du kernel dans GRUB jusqu'à l'affichage de l'invite de X : # 20 secondes
• Temps d'affichage complet du bureau après la saisie du mot de passe : # 9 secondes

Ces temps sont de beaucoup plus courts que ceux de l'ancien système : # 60 secondes pour le boot et # 35 secondes pour l'affichage du bureau. 

64bits + SSD ça décoiffe.

Afin de vérifier la puissance relative de cette machine j'ai comparé la durée de compilation d'un kernel 4.5 sur 4 machines de génération différentes :

Core i3 3330     (3.3Ghz)       10' 59''        référence 100% 
Core i3 4330     (3.4GHz)        9' 39'''       -14% 
Core I7 6700     (3.4/3.7GHz)    3' 37''        -67% 
Core I2 T8100    (2.1GHz)       50' 45''        +500%  vive ce vieux portable de 2009

La vitesse d'horloge des 3 machines n'est pas très différente (sauf pour le "vieux" portable) et on "voit" bien la différence entre machines à 2 coeurs et machine à 4 coeurs.