RE: Perte de configuration RAID

[David BERCOT]

Bonjour Thierry,

En effet, mon erreur (la deuxième en fait ;-)) a été de re-créer 
"directement" les 2 groupes... J'aurais pu les ré-importer en mode 
"foreign". Ca me servira pour la prochaine fois...


Je vais faire des tests complémentaires avec l'utilitaire de la carte 
RAID en ligne de commande pour voir s'il peut retrouver mes petits.


Et en effet, j'ai prévu de "regarder" directement les disques pour y 
trouver des données (j'ai un second groupe dans le même état mais sans 
sensibilité pour m'entraîner).


Merci pour ton aide.

David.

 Message d'origine 
Objet : Perte de configuration RAID
Date : lundi 18 décembre 2023 à 19:53 UTC+1
De : Th.A.C 
Pour : debian-user-french@lists.debian.org

Bonjour,

je fais des bricoles sur des serveurs Dell, mais rien d'extraordinaire.

De mémoire, on ne recrée pas un raid, mais on l'importe (un truc dans le 
genre "... foreign ...").
En général, quand on démarre le serveur avec des disques inconnus, s'il 
voit un raid compatible, il propose de l'activer.


Quand on le recrée, il écrit des choses sur la grappe. S'il a écrasé les 
infos par les nouvelles du 3eme groupe que tu as créé, je ne sais pas ce 
que ca va donner (à mon avis les infos des précédentes configurations 
sont perdues)..


A tester:
https://www.reddit.com/r/sysadmin/comments/6ebol2/raid_configuration_and_virtual_drive_missing_from/



Autres piste de réflexion:

- tes 2 premiers raids étaient sur les mêmes disques ou sur des groupes 
de disques différents?
Si c'est sur les mêmes disques, as-tu bien remis les bonnes valeurs 
(taille, strip, dans le même ordre(raid 0 puis raid 5), ...).
Si tu es sur de n'avoir que recréé les raids sans initialisation, il 
faut retrouver les bonnes valeurs de config.
Et si tu es sur de toi, essaye 'testdisk'. Il propose de sauvegarder les 
données avant de faire des modifications.


- essaye de lire les disques en 'brut' avec un hexdump pour voir si les 
données sont toujours la.



Bon courage
Thierry

Re: Perte de configuration RAID

[Th.A.C]

Bonjour,

je fais des bricoles sur des serveurs Dell, mais rien d'extraordinaire.

De mémoire, on ne recrée pas un raid, mais on l'importe (un truc dans le 
genre "... foreign ...").
En général, quand on démarre le serveur avec des disques inconnus, s'il 
voit un raid compatible, il propose de l'activer.


Quand on le recrée, il écrit des choses sur la grappe. S'il a écrasé les 
infos par les nouvelles du 3eme groupe que tu as créé, je ne sais pas ce 
que ca va donner (à mon avis les infos des précédentes configurations 
sont perdues)..


A tester:
https://www.reddit.com/r/sysadmin/comments/6ebol2/raid_configuration_and_virtual_drive_missing_from/



Autres piste de réflexion:

- tes 2 premiers raids étaient sur les mêmes disques ou sur des groupes 
de disques différents?
Si c'est sur les mêmes disques, as-tu bien remis les bonnes valeurs 
(taille, strip, dans le même ordre(raid 0 puis raid 5), ...).
Si tu es sur de n'avoir que recréé les raids sans initialisation, il 
faut retrouver les bonnes valeurs de config.
Et si tu es sur de toi, essaye 'testdisk'. Il propose de sauvegarder les 
données avant de faire des modifications.


- essaye de lire les disques en 'brut' avec un hexdump pour voir si les 
données sont toujours la.



Bon courage
Thierry

Re: Perte de configuration RAID

[didier gaumet]

Le 18/12/2023 à 10:47, David BERCOT a écrit :

Bonjour Didier,

Je te remercie pour ton mail mais tu cibles ici l'utilisation d'une 
solution RAID logicielle avec Mdadm.

Me concernant, il s'agit de RAID matériel avec une carte spécifique.

Mais je vais quand même regarder au cas où il y aurait quelque chose à 
prendre...


Déjà que j'y connais rien, si en plus je lis mal ton pessage, t'es pas 
sortie de l'auberge. Désolé :-)


une autre recherche sur "Dell PERC H330 linux raid metadata recovery" 
renvoie quelques éléments, dont le manuel utilisateur Dell de la carte, 
l'info que des zones de l'UEFI sont dédiées à l'exploitation de la 
carte, qu'on peut installer un truc qui se'appelle PERC Cli sous Linux 
pour gérer la carte en ligne de commande, etc... (j'ai pas creusé):

https://duckduckgo.com/?t=ftsa=Dell+PERC+H330+linux+raid+metadata+recovery=web

Bonne chance :-)

RE: Perte de configuration RAID

[David BERCOT]

Bonjour Didier,

Je te remercie pour ton mail mais tu cibles ici l'utilisation d'une 
solution RAID logicielle avec Mdadm.

Me concernant, il s'agit de RAID matériel avec une carte spécifique.

Mais je vais quand même regarder au cas où il y aurait quelque chose à 
prendre...


Bien cordialement,

David.

 Message d'origine 
Objet : Perte de configuration RAID
Date : lundi 18 décembre 2023 à 10:29 UTC+1
De : didier gaumet 
Pour : debian-user-french@lists.debian.org

Le 18/12/2023 à 10:08, David BERCOT a écrit :
[...]
J'ai voulu créer un 3ème groupe RAID et, au moment d'appliquer la 
configuration, le système a supprimé mes 2 premiers groupes !!!
Je les ai re-créés mais, malheureusement, il ne retrouve pas ses 
petits (et ne boote même pas sur Debian).

Manifestement, les meta-données ne sont pas les bonnes...

[...]

Merci d'avance, même pour de simples pistes...


Bonjour,

Je n'y connais rien et je n'ai jamais pratiqué le RAID, donc je ne 
réponds que parce que tu es prêt à te satisfaire de simples pistes :-)


Une recherche (ici sur duckduckgo mais on peut chercher ailleurs) avec 
l'expression "linux raid metadata recovery" renvoie quelques pistes qui 
ont l'air (de loin, vu mon niveau sur la question, et je n'ai survolé 
que les cinq premières réponses) intéressantes:

https://duckduckgo.com/?q=linux+raid+metadata+recovery=ftsa=web

Re: Perte de configuration RAID

[didier gaumet]

Le 18/12/2023 à 10:08, David BERCOT a écrit :
[...]
J'ai voulu créer un 3ème groupe RAID et, au moment d'appliquer la 
configuration, le système a supprimé mes 2 premiers groupes !!!
Je les ai re-créés mais, malheureusement, il ne retrouve pas ses petits 
(et ne boote même pas sur Debian).

Manifestement, les meta-données ne sont pas les bonnes...

[...]

Merci d'avance, même pour de simples pistes...


Bonjour,

Je n'y connais rien et je n'ai jamais pratiqué le RAID, donc je ne 
réponds que parce que tu es prêt à te satisfaire de simples pistes :-)


Une recherche (ici sur duckduckgo mais on peut chercher ailleurs) avec 
l'expression "linux raid metadata recovery" renvoie quelques pistes qui 
ont l'air (de loin, vu mon niveau sur la question, et je n'ai survolé 
que les cinq premières réponses) intéressantes:

https://duckduckgo.com/?q=linux+raid+metadata+recovery=ftsa=web

Perte de configuration RAID

[David BERCOT]

Bonjour,

Le sujet n'est pas directement lié à Debian mais je tente ma chance en 
me disant qu'il y a sûrement des personnes sur cette liste qui ont 
l'expérience ad hoc.
Si vous pensez que c'est trop hors-sujet, n'hésitez pas à revenir vers 
moi en direct pour ne pas polluer la liste...


Donc, sur un serveur (Dell PowerEdge R540 avec carte PERC H330), j'avais 
la configuration suivante :

- groupe RAID0 : Debian
- groupe RAID5 : données
J'ai voulu créer un 3ème groupe RAID et, au moment d'appliquer la 
configuration, le système a supprimé mes 2 premiers groupes !!!
Je les ai re-créés mais, malheureusement, il ne retrouve pas ses petits 
(et ne boote même pas sur Debian).

Manifestement, les meta-données ne sont pas les bonnes...

A priori, les disques n'ont pas été touchés et j'espère donc que tout 
est toujours là, notamment sur le second groupe (sur le premier, je 
pourrai toujours ré-installer Debian).


Est-ce que vous avez déjà fait face à une situation de ce type et trouvé 
une solution pour vous en sortir ?


Merci d'avance, même pour de simples pistes...

David.

Re: Peut ton faire du raid 10 logiciel?

[ptilou]

Le mercredi 4 janvier 2023 à 05:40:06 UTC+1, Olivier backup my spare a écrit :
> Bonjour 
> 
> J'ai récupéré le PC de ma mère. 
> J'ai mis une carte RAID chinoise (raid O, 1, 5, 10) 
> Problème. 2 disk 2 To et 2 disque 4 To 
> J'ai fait une grappe 2 to et une grappe 4 To en raid 0 
> Là, la carte refuse de faire du raid 10 
> 
> Puis je le faire avec la debian. Je n'ai jamais fait de raid logiciel 
> sous linux, alors je demande. 
> 
> 
Il n’a pas d’interets a faire cela, mais plutot utiliser la carte en raid, puis 
faire un volume lvm !

Sinon le raid ne peut etre que logiciel, et c’est un abus de langage que de 
parler de ce qui inscrit dans une rom, en binaires, y a un article sur ieee, 
qui est dispo au sous sol de la bnf avec une carte chercheur ….

Si non dans fstab dans le repertoire /etc, tu declare le systeme raid qui 
t’enchante …

— 
Ptilou

Re: Peut ton faire du raid 10 logiciel?

[Michel Verdier]

Le 25 janvier 2023 Daniel Caillibaud a écrit :

> L'intérêt du raid0 c'est de multiplier par 2 (quasiment) les perfs disques 
> (avec deux volumes
> dans le raid0), et j'avais compris qu'il fallait des volumes de tailles 
> voisines pour conserver
> ça.

Oui c'est vrai, pour éviter de remplir une partie et pas l'autre.

> J'imagine que ça dépend de la taille totale de datas par rapport à l'espace 
> dispo, mais ici
> avec du raid0 sur 2To+4To les perfs se dégradent pas dès qu'on atteint 4To 
> utilisés ?

Sans doute, j'ai jamais fait de bench avec un remplissage comme ça. Mais
dans ta config il sera bloqué s'il atteint les 4To. C'est le principe du
swap : on dégrade mais on bloque pas.

Re: Peut ton faire du raid 10 logiciel?

[Daniel Caillibaud]

Le 24/01/23 à 13:26, Michel Verdier  a écrit :
> En fait il faut 2 *partitions* de même taille pour chaque paire
> raid1. Mais on peut avoir des tailles différentes pour le raid0.

On peut, mais ça dégrade les perfs non ?

L'intérêt du raid0 c'est de multiplier par 2 (quasiment) les perfs disques 
(avec deux volumes
dans le raid0), et j'avais compris qu'il fallait des volumes de tailles 
voisines pour conserver
ça.

mdadm arrive à écrire simultanément sur ses deux volumes en raid0 même si l'un 
est nettement
plus gros que l'autre ?

J'imagine que ça dépend de la taille totale de datas par rapport à l'espace 
dispo, mais ici
avec du raid0 sur 2To+4To les perfs se dégradent pas dès qu'on atteint 4To 
utilisés ?

C'est juste par curiosité ;-)

-- 
Daniel

L'évolution de la pensée pré-situationniste entre l'école hégélienne
et le négativisme de l'infrastructure néo-nietzschéenne a-t-elle,
inconsciemment ou non, influencé la carrière de Raymond Poulidor ?
Pierre Desproges.

Re: Peut ton faire du raid 10 logiciel?

[Michel Verdier]

Le 24 janvier 2023 Daniel Caillibaud a écrit :

> Pour du raid10, il me semble qu'il faut 4 disques de même taille.
>
> Il vaut mieux faire d'abord les paires de raid1 puis le raid0 entre deux 
> paires (sinon avec la
> perte d'un seul disque tu perds tout).

En fait il faut 2 *partitions* de même taille pour chaque paire
raid1. Mais on peut avoir des tailles différentes pour le raid0.
Donc raid1 entre les 2 2To et raid1 entre les 2 4To, puis raid0 entre les
2 raid1, pour un total de 6To en raid10.

Re: Peut ton faire du raid 10 logiciel?

[Daniel Caillibaud]

Le 04/01/23 à 05:37, Olivier backup my spare  a 
écrit :
> Bonjour
> 
> J'ai récupéré le PC de ma mère.
> J'ai mis une carte RAID chinoise (raid O, 1, 5, 10)
> Problème. 2 disk 2 To et 2 disque 4 To
> J'ai fait une grappe 2 to et une grappe 4 To en raid 0
> Là, la carte refuse de faire du raid 10
> 
> Puis je le faire avec la debian. Je n'ai jamais fait de raid logiciel 
> sous linux, alors je demande.

J'arrive très longtemps après la demande, mais je me permet d'ajouter ce 
commentaire.

Pour du raid10, il me semble qu'il faut 4 disques de même taille.

Il vaut mieux faire d'abord les paires de raid1 puis le raid0 entre deux paires 
(sinon avec la
perte d'un seul disque tu perds tout).

Donc ici, je suggèrerais de couper les 4To en 2×2To, puis de faire des paires 
de 2To en raid1,
puis du raid0 sur les 2 paires (issus de disques différents), et conserver la 
dernière paire
(moitié de chacun des 4To) pour du raid1 peu accédé (du backup par ex).

Tu auras 4To en raid0 (bonnes perfs) + 2To en raid1 (qu'il vaut mieux ne pas 
trop solliciter
car ça concurrence ton raid0 vu que c'est les mêmes disques).

mdadm permet de faire tout ça sans carte raid dédiée (lvm aussi, mais en 
général on utilise
mdadm pour gérer le raid soft puis lvm pour découper les volumes, je sais pas 
vraiment si y'a
du gain de perf vs demander à lvm de gérer aussi le raid soft).

-- 
Daniel

On ne va tout de même pas se laisser abattre.
John F. Kennedy.

Re: Peut ton faire du raid 10 logiciel?

[Michel Verdier]

Le 4 janvier 2023 Olivier backup my spare a écrit :

> Là, la carte refuse de faire du raid 10
>
> Puis je le faire avec la debian. Je n'ai jamais fait de raid logiciel sous
> linux, alors je demande.

Oui ça marche très bien avec mdadm.

Peut ton faire du raid 10 logiciel?

[Olivier backup my spare]

Bonjour

J'ai récupéré le PC de ma mère.
J'ai mis une carte RAID chinoise (raid O, 1, 5, 10)
Problème. 2 disk 2 To et 2 disque 4 To
J'ai fait une grappe 2 to et une grappe 4 To en raid 0
Là, la carte refuse de faire du raid 10

Puis je le faire avec la debian. Je n'ai jamais fait de raid logiciel 
sous linux, alors je demande.




--
AI Gestionnaire d'infrastructure/ Gestionnaire de Parc.
Centre d'économie S**
Monero (XMR) - The secure, private, untraceable cryptocurrency
that keeps your money confidential.
Grassroots. Open source. Dedicated to privacy & freedom.
Monero || #xmrBEGIN:VCARD
VERSION:4.0
N:P.;Olivier;;;
NICKNAME:Backup my Spare
EMAIL;PREF=1:backup.my.sp...@gmail.com
URL:https://Deployadmin.com
TZ:Europe/Paris
FN:Olivier P.
ADR:;;;Rambouillet;;78120;France
END:VCARD


smime.p7s
Description: Signature cryptographique S/MIME

Re: grub2 uefi et raid

[Kohler Gerard]

Le 20/10/2021 à 06:43, Jean-Michel OLTRA a écrit :

 Bonjour,


Le mardi 19 octobre 2021, Kohler Gerard a écrit...



Le problème : je ne me rappelle plus quel est le Debian qui gère le Grub, ni
sur quel disque et quelle partition il est installé.

comment faire pour avoir ces réponses ?

Avec `fdisk -l` ou au menu de grub lors du boot (commande `find` de grub).


habituellement pour installer une nouvelle version je clone ma partition
système et je fais un upgrade. comment faire pour réinstaller Grub et sur
quelle partition/DD ?

Avec grub-install, je pense.


je vous remercie avec retard !,

après sauvegarde j'ai du tout réinstallé, avec un grub tout neuf.

le problème de base venais du fait que je clonais mes partitions avec 
gparted, et celui-ci marque les partitions clonées avec le même UUID que 
la partition d'origine, d’où un petit mélange.


Gérard

Re : Re: grub2 uefi et raid

[k6dedijon]

Bonjour,
La réponse de Wallace est bonne.
Mais elle nécessite un disque par distro.

Tu peux essayer de mettre une image de fond différente par distribution, mettre 
un écran de connexion différent (ssdm).
Tu peux aussi paramétrer Grub pour qu'il indique sur quelle partition est le 
système sur lequel tu vas démarrer.
Cela se traduira par une ligne de menu :
Debian X (on dev/sdYY)
X= numéro de version de Debiaan
YY= lettre du lecteur et le numéro de partition
Par exemple :
Debian 10 (on dev/sdc3)

Bon courage
Cassis



- Mail d'origine -
De: Wallace 
À: debian-user-french@lists.debian.org
Envoyé: Wed, 20 Oct 2021 12:38:55 +0200 (CEST)
Objet: Re: grub2 uefi et raid

Tu t'es aventuré dans une installation compliquée.

Pour ma part j'ai arrêté de faire du multiboot géré par un OS ça finit 
toujours mal lors d'une réinstallation d'un OS.

Sur mon ordi fixe qui a plusieurs OS, lorsque je fais une installation 
je débranche tous les disques non concernés, puis quand j'ai tout 
rebranché, je fais F8 pour choisir le disque sur lequel je veux booter 
si j'en veux un différent du par défaut.

Bon courage

Le 20/10/2021 à 06:43, Jean-Michel OLTRA a écrit :
>  Bonjour,
>
>
> Le mardi 19 octobre 2021, Kohler Gerard a écrit...
>
>
>> Le problème : je ne me rappelle plus quel est le Debian qui gère le Grub, ni
>> sur quel disque et quelle partition il est installé.
>>
>> comment faire pour avoir ces réponses ?
> Avec `fdisk -l` ou au menu de grub lors du boot (commande `find` de grub).
>
>> habituellement pour installer une nouvelle version je clone ma partition
>> système et je fais un upgrade. comment faire pour réinstaller Grub et sur
>> quelle partition/DD ?
> Avec grub-install, je pense.
>

Re: grub2 uefi et raid

[Wallace]

Tu t'es aventuré dans une installation compliquée.

Pour ma part j'ai arrêté de faire du multiboot géré par un OS ça finit 
toujours mal lors d'une réinstallation d'un OS.


Sur mon ordi fixe qui a plusieurs OS, lorsque je fais une installation 
je débranche tous les disques non concernés, puis quand j'ai tout 
rebranché, je fais F8 pour choisir le disque sur lequel je veux booter 
si j'en veux un différent du par défaut.


Bon courage

Le 20/10/2021 à 06:43, Jean-Michel OLTRA a écrit :

 Bonjour,


Le mardi 19 octobre 2021, Kohler Gerard a écrit...



Le problème : je ne me rappelle plus quel est le Debian qui gère le Grub, ni
sur quel disque et quelle partition il est installé.

comment faire pour avoir ces réponses ?

Avec `fdisk -l` ou au menu de grub lors du boot (commande `find` de grub).


habituellement pour installer une nouvelle version je clone ma partition
système et je fais un upgrade. comment faire pour réinstaller Grub et sur
quelle partition/DD ?

Avec grub-install, je pense.

Re: grub2 uefi et raid

[Jean-Michel OLTRA]

Bonjour,


Le mardi 19 octobre 2021, Kohler Gerard a écrit...


> Le problème : je ne me rappelle plus quel est le Debian qui gère le Grub, ni
> sur quel disque et quelle partition il est installé.
> 
> comment faire pour avoir ces réponses ?

Avec `fdisk -l` ou au menu de grub lors du boot (commande `find` de grub).

> habituellement pour installer une nouvelle version je clone ma partition
> système et je fais un upgrade. comment faire pour réinstaller Grub et sur
> quelle partition/DD ?

Avec grub-install, je pense.

-- 
jm

grub2 uefi et raid

[Kohler Gerard]

bonjour,

voulant installer la version testing je me heurte à un problème bête :

Ma machine est dotée d'UEFI.

j'ai 3 DD dont les deux premiers sont montés en RAID1 (/dev/sda et 
/dev/sdb) et ils contiennent mes données, le troisième (/dev/sdc) est 
mon disque système.


sur mon disque système j'ai plusieurs partitions avec des versions de 
Debian différentes .


Au démarrage Grub me permet de choisir entre les différents systèmes 
Debian (j'ai 5 Debian différents, des versions historiques ...).


Le problème : je ne me rappelle plus quel est le Debian qui gère le 
Grub, ni sur quel disque et quelle partition il est installé.


comment faire pour avoir ces réponses ?

autre question :

habituellement pour installer une nouvelle version je clone ma partition 
système et je fais un upgrade. comment faire pour réinstaller Grub et 
sur quelle partition/DD ?


merci de votre aide

Gérard

Re: Raid 1

[Pascal Hambourg]

Le 25/09/2019 à 09:25, Erwan RIGOLLOT a écrit :


Un raid 1 sur 3 disques fait que les 3 disques ont les données et t'autorise 
donc à perdre jusqu'à 2 disques sans perte de données mais dans ce cas les 3 
disques fonctionneront en permanence et s'userons mais tu n'auras pas de temps 
de reconstruction en cas de perte d'un disque.


Si, il y aura de toute façon un temps de reconstruction quand le disque 
défaillant sera remplacé.


PS : bizarre que ce message soit arrivé plusieurs heures après avoir été 
envoyé.

RE: Raid 1

[Erwan RIGOLLOT]

Hello,

Si tu choisis de mettre le disque en spare, il ne se mettra en marche que quand 
un autre tombera en panne.
C’est-à-dire qu'il ne s'usera pas en fonctionnement normal mais cela engendrera 
un temps de reconstruction du raid (les données devront être copiées dessus).

Un raid 1 sur 3 disques fait que les 3 disques ont les données et t'autorise 
donc à perdre jusqu'à 2 disques sans perte de données mais dans ce cas les 3 
disques fonctionneront en permanence et s'userons mais tu n'auras pas de temps 
de reconstruction en cas de perte d'un disque.

C'est un choix à faire ...

Bonne journée !

Erwan
-Message d'origine-
De : steve  
Envoyé : mercredi 25 septembre 2019 09:07
À : duf 
Objet : Raid 1

Bonjour,

J'ai trois disques que je souhaiterais monter en Raid 1.

J'ai le choix entre créer une grappe de deux disque plus un spare ou alors 
créer une grappe de trois disques sans spare.

Qu'est-ce qui est le mieux ?

Merci

Steve

Re: Raid 1

[Pascal Hambourg]

Le 25/09/2019 à 12:20, Pascal Hambourg a écrit :

Le 25/09/2019 à 11:39, steve a écrit :


L'argument du spare qui ne travaille pas, et donc ne s'use pas, est un
bon argument, par exemple.


Oui. Du moins qui s'use moins que s'il travaillait, mais plus que s'il 
était sur une étagère. Il reste sous tension et soumis à la chaleur de 
la machine.


Un autre argument est le temps de reconstruction. Avec les disques de 
très grande capacité (qui augmente plus vite que le débit), la 
reconstruction prend de plus en plus de temps - plusieurs heures - et le 
risque que le seul disque actif restant, qui a subi la même usure, 
flanche à son tour avant la fin n'est pas négligeable, d'autant plus 
qu'il est plus fortement sollicité lors de la reconstruction qu'en temps 
normal.


Et si la performance importe, le RAID 1 peut faire de la répartition de 
charge en lecture entre tous les disques actifs.

Re: Raid 1

[Pascal Hambourg]

Le 25/09/2019 à 11:39, steve a écrit :

Le 25-09-2019, à 10:12:49 +0200, Pascal Hambourg a écrit :


Le 25/09/2019 à 09:07, steve a écrit :

Bonjour,

J'ai trois disques que je souhaiterais monter en Raid 1.

J'ai le choix entre créer une grappe de deux disque plus un spare ou
alors créer une grappe de trois disques sans spare.

Qu'est-ce qui est le mieux ?


Le mieux pour quoi ?


Pour moi.


Je parlais du critère d'optimisation choisi.


L'argument du spare qui ne travaille pas, et donc ne s'use pas, est un
bon argument, par exemple.


Oui. Du moins qui s'use moins que s'il travaillait, mais plus que s'il 
était sur une étagère. Il reste sous tension et soumis à la chaleur de 
la machine.


Un autre argument est le temps de reconstruction. Avec les disques de 
très grande capacité (qui augmente plus vite que le débit), la 
reconstruction prend de plus en plus de temps - plusieurs heures - et le 
risque que le seul disque actif restant, qui a subi la même usure, 
flanche à son tour avant la fin n'est pas négligeable, d'autant plus 
qu'il est plus fortement sollicité lors de la reconstruction qu'en temps 
normal.

Re: Raid 1

[steve]

Le 25-09-2019, à 11:21:42 +0200, Jean-Michel OLTRA a écrit :


Le mercredi 25 septembre 2019, steve a écrit...

J'ai le choix entre créer une grappe de deux disque plus un spare ou

Je fonctionne comme ça depuis des années. Si un disque présente des
faiblesses, ou une partie de disque, le spare prend le relais. Ce qui laisse
le temps de racheter un autre disque pour reconstituer l'ensemble.


Moi aussi. Cependant, j'ai eu un soucis il y a quelques temps avec mon
système et je pensais que la source était un des disques de la grappe.
Je l'ai donc sorti de la grappe mais le soucis persistait. J'ai
finalement trouvé le problème, qui n'était pas du tout lié au disque en
question. Par paresse, j'ai laissé l'été passer, et je viens de remettre
ce disque dans la grappe sans me souvenir qu'il était en spare à
l'origine.

J'ai donc maintenant une grappe avec 3 disques et plus de spare. D'où ma
question.

Je pense comme toi que la solution 2 disques + spare est une bonne
option. Avant de retirer un des disques de la grappe et de le remettre
en spare, je voulais avoir le sentiment de la liste.

Re: Raid 1

[Jean-Michel OLTRA]

Bonjour,


Le mercredi 25 septembre 2019, steve a écrit...


> J'ai le choix entre créer une grappe de deux disque plus un spare ou

Je fonctionne comme ça depuis des années. Si un disque présente des
faiblesses, ou une partie de disque, le spare prend le relais. Ce qui laisse
le temps de racheter un autre disque pour reconstituer l'ensemble.


-- 
jm

Re: Raid 1

[steve]

Le 25-09-2019, à 10:12:49 +0200, Pascal Hambourg a écrit :


Le 25/09/2019 à 09:07, steve a écrit :

Bonjour,

J'ai trois disques que je souhaiterais monter en Raid 1.

J'ai le choix entre créer une grappe de deux disque plus un spare ou
alors créer une grappe de trois disques sans spare.

Qu'est-ce qui est le mieux ?


Le mieux pour quoi ?


Pour moi.


Le mieux dans l'absolu, ça n'existe pas.


On est bien d'accord, ma question était une question ouverte.

L'argument du spare qui ne travaille pas, et donc ne s'use pas, est un
bon argument, par exemple.

Re: Raid 1

[Pascal Hambourg]

Le 25/09/2019 à 10:14, kaliderus a écrit :



Si tu veux de la redondance (donc du Raid 1),


Non. On peut aussi avoir de la redondance avec du RAID 4, 5, 6 ou 10.


il te faut un disque de parité.


Non, pas forcément. Les RAID 1 et 10 n'ont pas de parité. Seul le RAID 4 
a un disque de parité dédié. Les RAID 5 et 6 ont une parité répartie sur 
tous les disques actifs.



" une grappe de trois disques sans spare " je ne sais pas trop ce que
c'est ; à priori du Raid 0


Tu confirmes que tu ne sais pas de quoi tu parles et tu racontes 
n'importe quoi.

RE: Raid 1

[Erwan RIGOLLOT]

Heu, je ne suis pas d'accord avec toi.
Un disque de spare c'est un disque inactif.
On peut faire un raid 1 sur 3 disques et les trois sont actifs et contiennent 
les données et donc aucun spare.

-Message d'origine-
De : kaliderus  
Envoyé : mercredi 25 septembre 2019 10:14
À : duf 
Objet : Re: Raid 1

Le mer. 25 sept. 2019 à 09:07, steve  a écrit :
>
> Bonjour,
>
> J'ai trois disques que je souhaiterais monter en Raid 1.
>
> J'ai le choix entre créer une grappe de deux disque plus un spare ou 
> alors créer une grappe de trois disques sans spare.
Si tu veux de la redondance (donc du Raid 1), il te faut un disque de parité.

>
> Qu'est-ce qui est le mieux ?
Lire les documentations associées afin de comprendre les différentes 
architectures :-) " une grappe de trois disques sans spare " je ne sais pas 
trop ce que c'est ; à priori du Raid 0 qui n'as de " redondant " que le nom, et 
qui dans les faits n'est que de globaliser 3 disques en une seule unité 
logique, et si tu perd un disque tu perd tout, l'anti-thèse de la notion de 
dedondance.

Bon amusement.

Re: Raid 1

[Eric Degenetais]

bonjour

Le mer. 25 sept. 2019 à 10:14, kaliderus  a écrit :
>
> Le mer. 25 sept. 2019 à 09:07, steve  a écrit :
> >
> > Bonjour,
> >
> > J'ai trois disques que je souhaiterais monter en Raid 1.
> >
> > J'ai le choix entre créer une grappe de deux disque plus un spare ou
> > alors créer une grappe de trois disques sans spare.
> Si tu veux de la redondance (donc du Raid 1), il te faut un disque de parité.
>
> >
> > Qu'est-ce qui est le mieux ?
> Lire les documentations associées afin de comprendre les différentes
> architectures :-)
> " une grappe de trois disques sans spare " je ne sais pas trop ce que
> c'est ; à priori du Raid 0 qui n'as de " redondant " que le nom, et
Non : ça peut être du raid1 (mirroring) qui met l'accent sur la
redondance (3 copies), en sacrifiant la capacité (3 disques pour
stocker un volume de données équivalent au plus petit d'entre eux, ou
à un seul d'netre eux s'ils sont identiques).
> qui dans les faits n'est que de globaliser 3 disques en une seule
> unité logique, et si tu perd un disque tu perd tout, l'anti-thèse de
Donc non, dans ce cas tu peux aller jusqu'à en perdre deux (en faisant
abstraction des risques de corruption, pour lesquels il faut comparer
au moins trois disques entre eux).
> la notion de dedondance.
>
> Bon amusement.
>

Cordialement
__
Éric Dégenètais
Henix

http://www.henix.com
http://www.squashtest.org

Re: Raid 1

[kaliderus]

Le mer. 25 sept. 2019 à 09:07, steve  a écrit :
>
> Bonjour,
>
> J'ai trois disques que je souhaiterais monter en Raid 1.
>
> J'ai le choix entre créer une grappe de deux disque plus un spare ou
> alors créer une grappe de trois disques sans spare.
Si tu veux de la redondance (donc du Raid 1), il te faut un disque de parité.

>
> Qu'est-ce qui est le mieux ?
Lire les documentations associées afin de comprendre les différentes
architectures :-)
" une grappe de trois disques sans spare " je ne sais pas trop ce que
c'est ; à priori du Raid 0 qui n'as de " redondant " que le nom, et
qui dans les faits n'est que de globaliser 3 disques en une seule
unité logique, et si tu perd un disque tu perd tout, l'anti-thèse de
la notion de dedondance.

Bon amusement.

Re: Raid 1

[Pascal Hambourg]

Le 25/09/2019 à 09:07, steve a écrit :

Bonjour,

J'ai trois disques que je souhaiterais monter en Raid 1.

J'ai le choix entre créer une grappe de deux disque plus un spare ou
alors créer une grappe de trois disques sans spare.

Qu'est-ce qui est le mieux ?


Le mieux pour quoi ?
Le mieux dans l'absolu, ça n'existe pas.

Raid 1

[steve]

Bonjour,

J'ai trois disques que je souhaiterais monter en Raid 1.

J'ai le choix entre créer une grappe de deux disque plus un spare ou
alors créer une grappe de trois disques sans spare.

Qu'est-ce qui est le mieux ?

Merci

Steve

Re: installation Buster et raid 1

[Pascal Hambourg]

Le 06/11/2017 à 11:38, Kohler Gerard a écrit :

bonjour,

je suis actuellement en Stretch avec un raid 1 pour ma partition /home

j'aimerai passer en debian buster, sans perdre mes données ;-)


Si l'installateur de buster est comme les versions précédentes, il 
détectera et assemblera automatiquement tes ensembles RAID et tu pourras 
en faire ce que bon te semble. Par exemple en monter un sur /home. Il 
faudra juste faire attention à ne pas marquer le volume "à formater".


Débrancher un des disques du RAID pendant l'installation, c'est courir 
le risque de devoir lancer une resynchronisation de 4 To (c'est long) 
lorsque le disque sera rebranché.

Re: installation Buster et raid 1

[Kohler Gerard]

effectivement ce n'est pas l'idéal,
j'utilise un RAID 1 avec 2 DD de 4To pour mes données, et je sauvegarde 
sur un NAS
je n'ai pas mis / sur le RAID pour des raisons historiques : j'ai 
construit mon RAID après une perte de données brutale lors d'une 
sauvegarde sur mon NAS : DD ayant une panne de carte, avec corruption de 
toutes les données sur le disque et sur le NAS, irrécupérable :'(
plus de 3 To partis en fumée, heureusement j'ai pu récupérer une partie 
de mes données sur mon portable.

Ceci dit, la même panne peut de nouveau arriver, et tout corrompre
 merci de m'avoir confirmer la méthodologie

Gerard

Le 06/11/2017 à 11:59, daniel huhardeaux a écrit :

Le 06/11/2017 à 11:38, Kohler Gerard a écrit :

bonjour,

je suis actuellement en Stretch avec un raid 1 pour ma partition /home

j'aimerai passer en debian buster, sans perdre mes données ;-)

ma table de partition :

/dev/sda1 linux-raid /dev/md0

/dev/sda2 linux-raid /dev/md1

/dev/sdb1 linux-raid /dev/md0

/dev/sdb2 linux-raid /dev/md1

/dev/md0 linux-swap

/dev/md1 ext3 /home

/dev/sdc1 fat32 /boot/efi

/dev/sdc2 ext4 /

/dev/sdc3 ext4 partition prévue pour installer buster


j'avoue que je stresse un peu pour l'installation de buster

quelle stratégie pour que sous buster je retrouve mon raid sans 
perdre mes données


Vu que sdc est un 3eme disque, si tu ne dis rien à l'installation tout 
se passera sur ce disque. Tu pourras ensuite, une fois buster 
installé, modifier fstab afin d'y placer ton /home qui est en raid. 
Une autre précaution si tu insistes ;) est de débrancher sdb avant 
l'installation, tu auras ainsi un disque de secours de ton raid pour 
le cas ou.


Cela dit, si tu fais attention, pas de soucis, tu peux donner ton home 
raid lors de l'installation, suffit de ne pas demander le formatage.


Pour information, pourquoi / n'est pas en raid? J'ai l'impression que 
tu utilises le raid de ton /home comme sauvegarde. Si c'est le cas, ce 
n'est pas IMHO une bonne approche.

Re: installation Buster et raid 1

[Kohler Gerard]

merci,

sauvegarde sur un NAS tous les jours, donc pas de problème, mais 
rapatrier 3 To de données si on peut éviter !




Le 06/11/2017 à 12:06, Pierre L. a écrit :

Bonjour Gérard,

Déjà étape n°1 si je peux me permettre, la sauvegarde des données si
cela n'a pas encore été réalisé :)

Je laisse la parole aux connaisseurs pour la suite ;)



Le 06/11/2017 à 11:38, Kohler Gerard a écrit :

quelle stratégie pour que sous buster je retrouve mon raid sans perdre
mes données

Re: installation Buster et raid 1

[Pierre L.]

Bonjour Gérard,

Déjà étape n°1 si je peux me permettre, la sauvegarde des données si
cela n'a pas encore été réalisé :)

Je laisse la parole aux connaisseurs pour la suite ;)



Le 06/11/2017 à 11:38, Kohler Gerard a écrit :
> quelle stratégie pour que sous buster je retrouve mon raid sans perdre
> mes données




signature.asc
Description: OpenPGP digital signature

Re: installation Buster et raid 1

[daniel huhardeaux]

Le 06/11/2017 à 11:38, Kohler Gerard a écrit :

bonjour,

je suis actuellement en Stretch avec un raid 1 pour ma partition /home

j'aimerai passer en debian buster, sans perdre mes données ;-)

ma table de partition :

/dev/sda1 linux-raid /dev/md0

/dev/sda2 linux-raid /dev/md1

/dev/sdb1 linux-raid /dev/md0

/dev/sdb2 linux-raid /dev/md1

/dev/md0 linux-swap

/dev/md1 ext3 /home

/dev/sdc1 fat32 /boot/efi

/dev/sdc2 ext4 /

/dev/sdc3 ext4 partition prévue pour installer buster


j'avoue que je stresse un peu pour l'installation de buster

quelle stratégie pour que sous buster je retrouve mon raid sans perdre 
mes données


Vu que sdc est un 3eme disque, si tu ne dis rien à l'installation tout 
se passera sur ce disque. Tu pourras ensuite, une fois buster installé, 
modifier fstab afin d'y placer ton /home qui est en raid. Une autre 
précaution si tu insistes ;) est de débrancher sdb avant l'installation, 
tu auras ainsi un disque de secours de ton raid pour le cas ou.


Cela dit, si tu fais attention, pas de soucis, tu peux donner ton home 
raid lors de l'installation, suffit de ne pas demander le formatage.


Pour information, pourquoi / n'est pas en raid? J'ai l'impression que tu 
utilises le raid de ton /home comme sauvegarde. Si c'est le cas, ce 
n'est pas IMHO une bonne approche.


--
Daniel

installation Buster et raid 1

[Kohler Gerard]

bonjour,

je suis actuellement en Stretch avec un raid 1 pour ma partition /home

j'aimerai passer en debian buster, sans perdre mes données ;-)

ma table de partition :

/dev/sda1 linux-raid /dev/md0

/dev/sda2 linux-raid /dev/md1

/dev/sdb1 linux-raid /dev/md0

/dev/sdb2 linux-raid /dev/md1

/dev/md0 linux-swap

/dev/md1 ext3 /home

/dev/sdc1 fat32 /boot/efi

/dev/sdc2 ext4 /

/dev/sdc3 ext4 partition prévue pour installer buster


j'avoue que je stresse un peu pour l'installation de buster

quelle stratégie pour que sous buster je retrouve mon raid sans perdre 
mes données



merci de votre aide


Gerard

Re: Performance RAID instable

[Seb]

Merci Pascal pour les explications !


Pascal Hambourg (Fri, 20 Oct 2017):


Le 20/10/2017 à 09:10, Seb a écrit :



Pourquoi 4 Go ? C'est un peu arbitraire.
As-tu essayé d'autres valeurs entre 4 et 8 Go ?


Il me semble que le PAE permet au noyau d'utiliser la RAM au-delà de 4 Go:


Cette formulation est ambiguë.

PAE étend l'espace d'adressage en mémoire physique des processeurs 32 bits de 
4 Gio à 64 Gio. Mais cet espace ne contient pas que la RAM système. Il 
contient aussi les plages d'adresses des mémoires non volatiles du firmware 
de la carte mère et des périphériques internes comme la carte graphique, de 
la mémoire des mêmes périphériques permettant au système de transférer des 
données avec eux...


Le pseudo-fichier /proc/iomem recense les plages utilisées de l'espace 
mémoire physique.


Un système d'exploitation 32 bits sans PAE n'étant pas capable d'adresser 
au-delà de 4 Gio, toutes les plages autres que la RAM système doivent être 
accessibles à des adresses en-deça de cette limite. La plage d'adresse 
réservée aux périphériques est parfois appelée "PCI hole". Cela implique que 
la quantité de RAM système effectivement accessible à des adresses en-deça de 
4 Gio sera nécessairement inférieure à 4 Gio, typiquement de l'ordre de 3,5 
Go. Il ne faut pas confondre cette diminution avec la partie de la RAM 
système qui est réservée au GPU intégré.


La partie de la RAM système qui ne peut être adressée dans la plage en-deçà 
de 4 Gio est accessible à des adresses au-delà de 4 Gio donc uniquement par 
un système 32 bits avec PAE ou 64 bits.


Si par "au-delà de 4 Gio" tu voulais parler des adresses, alors oui. Mais si 
tu voulais parler de la quantité, alors non, la limite est plus basse 
notamment à cause du "PCI hole". Utiliser 4 Gio de RAM avec un système 32 
bits requiert PAE.


Je me suis dit que le noyau devait avoir des fonctions pour des RAM d'au 
plus 4 Go, et des astuces en plus pour les RAM au-delà, et que ce sont ces 
dernières qui sont actuellement buguées. Comme « ça marche », l'hypothèse a 
l'air correcte. Mais effectivement, non, je n'ai pas tenté 6 Go. Je ne vois 
pas de raison pour que ça marche.


PAE n'est pas juste une fonction qu'on active uniquement pour accéder aux 
adresses mémoire au-delà de 4 Gio. C'est une réorganisation permanente de la 
façon d'accéder à la mémoire physique. Avec un noyau PAE, les mécanismes de 
PAE sont à l'oeuvre quelle que soit la quantité de mémoire utilisable ou 
utilisée.


Bref, tout ça pour dire que la limite de 4 Gio de RAM que tu as fixée est 
arbitraire du point de vue de PAE car elle est déjà supérieure à la quantité 
utilisable sans PAE.


Par contre je me rappelle un commentaire de Linus Torvalds il y a déjà fort 
longtemps disant en substance qu'au-delà de 8 Gio de RAM, il valait mieux 
utiliser un noyau 64 bits car la gestion d'une telle quantité de mémoire par 
un noyau 32 bits avec PAE risquait d'être moins performante. Il ne faut pas 
oublier que même avec PAE l'espace d'adressage en mémoire virtuelle reste 
limité à 4 Gio, et l'espace réservé au noyau dans celui-ci à 1 Gio (3 Gio 
pour le processus).

Re: Performance RAID instable

[Pascal Hambourg]

Le 20/10/2017 à 09:10, Seb a écrit :



Pourquoi 4 Go ? C'est un peu arbitraire.
As-tu essayé d'autres valeurs entre 4 et 8 Go ?


Il me semble que le PAE permet au noyau d'utiliser la RAM au-delà de 4 Go:


Cette formulation est ambiguë.

PAE étend l'espace d'adressage en mémoire physique des processeurs 32 
bits de 4 Gio à 64 Gio. Mais cet espace ne contient pas que la RAM 
système. Il contient aussi les plages d'adresses des mémoires non 
volatiles du firmware de la carte mère et des périphériques internes 
comme la carte graphique, de la mémoire des mêmes périphériques 
permettant au système de transférer des données avec eux...


Le pseudo-fichier /proc/iomem recense les plages utilisées de l'espace 
mémoire physique.


Un système d'exploitation 32 bits sans PAE n'étant pas capable 
d'adresser au-delà de 4 Gio, toutes les plages autres que la RAM système 
doivent être accessibles à des adresses en-deça de cette limite. La 
plage d'adresse réservée aux périphériques est parfois appelée "PCI 
hole". Cela implique que la quantité de RAM système effectivement 
accessible à des adresses en-deça de 4 Gio sera nécessairement 
inférieure à 4 Gio, typiquement de l'ordre de 3,5 Go. Il ne faut pas 
confondre cette diminution avec la partie de la RAM système qui est 
réservée au GPU intégré.


La partie de la RAM système qui ne peut être adressée dans la plage 
en-deçà de 4 Gio est accessible à des adresses au-delà de 4 Gio donc 
uniquement par un système 32 bits avec PAE ou 64 bits.


Si par "au-delà de 4 Gio" tu voulais parler des adresses, alors oui. 
Mais si tu voulais parler de la quantité, alors non, la limite est plus 
basse notamment à cause du "PCI hole". Utiliser 4 Gio de RAM avec un 
système 32 bits requiert PAE.


Je me suis dit que le noyau devait avoir des fonctions pour des RAM d'au 
plus 4 Go, et des astuces en plus pour les RAM au-delà, et que ce sont 
ces dernières qui sont actuellement buguées. Comme « ça marche », 
l'hypothèse a l'air correcte. Mais effectivement, non, je n'ai pas tenté 
6 Go. Je ne vois pas de raison pour que ça marche.


PAE n'est pas juste une fonction qu'on active uniquement pour accéder 
aux adresses mémoire au-delà de 4 Gio. C'est une réorganisation 
permanente de la façon d'accéder à la mémoire physique. Avec un noyau 
PAE, les mécanismes de PAE sont à l'oeuvre quelle que soit la quantité 
de mémoire utilisable ou utilisée.


Bref, tout ça pour dire que la limite de 4 Gio de RAM que tu as fixée 
est arbitraire du point de vue de PAE car elle est déjà supérieure à la 
quantité utilisable sans PAE.


Par contre je me rappelle un commentaire de Linus Torvalds il y a déjà 
fort longtemps disant en substance qu'au-delà de 8 Gio de RAM, il valait 
mieux utiliser un noyau 64 bits car la gestion d'une telle quantité de 
mémoire par un noyau 32 bits avec PAE risquait d'être moins performante. 
Il ne faut pas oublier que même avec PAE l'espace d'adressage en mémoire 
virtuelle reste limité à 4 Gio, et l'espace réservé au noyau dans 
celui-ci à 1 Gio (3 Gio pour le processus).

Re: Performance RAID instable

[Seb]

Bonjour,


Il y a un détail qui m'interpelle. Pourquoi la gestion mémoire avec PAE 
n'impacte (apparement) que le système RAID logiciel du noyau ?


Chez moi seuls les tableaux RAID étaient affectés mais... je n'utilise que 
du RAID. D'autres ont signalé le même problème sur des disques isolés et 
même avec un clef USB. C'est donc seulement ma présentation qui donnait 
cet angle RAID (je pensais que le problème pouvait provenir de la gestion 
du RAID, idée plus immédiate que la gestion de la RAM).



Pourquoi 4 Go ? C'est un peu arbitraire.
As-tu essayé d'autres valeurs entre 4 et 8 Go ?


Il me semble que le PAE permet au noyau d'utiliser la RAM au-delà de 4 Go:
https://fr.wikipedia.org/wiki/Extension_d%27adresse_physique
Je me suis dit que le noyau devait avoir des fonctions pour des RAM d'au 
plus 4 Go, et des astuces en plus pour les RAM au-delà, et que ce sont ces 
dernières qui sont actuellement buguées. Comme « ça marche », l'hypothèse 
a l'air correcte. Mais effectivement, non, je n'ai pas tenté 6 Go. Je ne 
vois pas de raison pour que ça marche.



Seb.

Re: Performance RAID instable

[Pascal Hambourg]

Le 19/10/2017 à 16:06, Seb a écrit :


Merci beaucoup pour l'aide que vous m'avez apportée dans le diagnostic 
du problème. C'était bien un souci de gestion de la mémoire lié au PAE.


Sur la machine à la maison j'ai limité la RAM à 4 Go et depuis, la 
performance des disques est stable (980 Mo/s de moyenne).


Pourquoi 4 Go ? C'est un peu arbitraire.
As-tu essayé d'autres valeurs entre 4 et 8 Go ?

Re : Performance RAID instable

[Thierry Bugier]

Bonjour

Le jeudi 19 octobre 2017 à 16:06 +0200, Seb a écrit :
> Bonjour,
> 
> 
> Merci beaucoup pour l'aide que vous m'avez apportée dans le
> diagnostic du 
> problème. C'était bien un souci de gestion de la mémoire lié au PAE.
> 
> Sur la machine à la maison j'ai limité la RAM à 4 Go et depuis, la 
> performance des disques est stable (980 Mo/s de moyenne).
> 
> Sur la machine au bureau, 4 Go de RAM est trop juste pour InDesign
> dans 
> une VirtualBox alors j'ai réinstallé en amd64.
> 
> 
> Seb.

Il y a un détail qui m'interpelle. Pourquoi la gestion mémoire avec PAE
n'impacte (apparement) que le système RAID logiciel du noyau ?

Re: Performance RAID instable

[Seb]

Bonjour,


Merci beaucoup pour l'aide que vous m'avez apportée dans le diagnostic du 
problème. C'était bien un souci de gestion de la mémoire lié au PAE.


Sur la machine à la maison j'ai limité la RAM à 4 Go et depuis, la 
performance des disques est stable (980 Mo/s de moyenne).


Sur la machine au bureau, 4 Go de RAM est trop juste pour InDesign dans 
une VirtualBox alors j'ai réinstallé en amd64.



Seb.

Re: Performance RAID instable

[Seb]

Bonjour,


La semaine dernière, sur l'une des deux machines dont la performance 
disques est instable, j'avais installé un noyau 3.16. Le système a booté 
sans soucis, et depuis les chutes brutales et durables de performance ont 
cessé. J'ai uploadé un graphique:

https://framapic.org/2CBbZrCPNdnf/oQyFGaq0gACj.png

Au bruit près, la performance stable est d'environ 350 Mo/s. Cela permet 
de supposer qu'une génération suivante de noyaux a tenté d'optimiser la 
gestion de la mémoire (noyau 32 bits PAE), atteignant des vitesses de 
1000 Mo/s avec le même matériel, mais hélas cela conduisait à des 
« plantages » (chute vers < 1 Mo/s). La toute dernière version du noyau 
améliore un peu les choses, mais pas de manière décisive.


Il me reste à tester sur quelques jours le comportement d'un noyau 4.12 
avec la ligne mem=3500m lors du boot. Provisoirement, c'est un noyau 3.16 
qui m'apporte le plus de confort.



Seb.

Re: Performance RAID instable

[BERTRAND Joel]

Pascal Hambourg a écrit :

Le 05/10/2017 à 13:34, BERTRAND Joël a écrit :

 Je pense (mais je n'ai pas regardé, il y a longtemps que je ne
bidouille plus le noyau Linux) qu'avec moins de 4 Go de mémoire, même
avec PAE, le système ne va pas essayer de mapper la mémoire sur plus
de 32 bits d'adresses, donc n'essayera pas d'étendre l'adressage au-delà.


D'après ce que j'ai compris en lisant

l'activation de PAE modifie la structure des tables de pages (avec
notamment un niveau supplémentaire), quelle que soit la quantité de
mémoire physique à adresser. Je ne pense pas que le fait que la totalité
de la mémoire physique soit adressable avec 32 bits y change quelque chose.


	Personnellement, je ne fais pas d'hypothèse sur la complexité de la 
grouille rajoutée par PAE (j'ai des vieux souvenirs des problèmes de 
gestion de la mémoire sur sparc32 entre le 2.0 et le 2.2...). J'ai vu 
des trucs tellement ma fichus dans les noyaux Linux... D'autant que les 
noyaux i686 avec plus de 4Go de mémoire doivent être aujourd'hui 
marginaux. Je ne suis pas sûr qu'il y ait encore un réel effort là-dessus.


Cordialement,

JKB

Re: Performance RAID instable

[BERTRAND Joel]

Frédéric MASSOT a écrit :

Le 05/10/2017 à 11:12, BERTRAND Joël a écrit :

Seb a écrit :


Bonjour Pascal,



Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait
: utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?


Ah oui, c'est une bonne idée.

Si j'appelle sur une machine en Debian 9
apt-cache search linux-image
je ne vois pas de noyau 3.16 .

Dans la FAQ Debian, chapitre "Debian and the kernel", je ne vois pas de
solution packagée indiquée; d'un autre côté, elle ne mentionne pas non
plus les backports pour avoir, au contraire, un noyau plus récent.

Y a-t-il une méthode standard Debian qui me permettrait d'installer sans
trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne
page web m'irait amplement.)


Avec un init systemV, c'est assez trivial. Avec la grouille
systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire
ça, cela s'est soldé par un échec.


À cause du bug (865866) de LibreOffice Writer j'utilise un noyau 3.16
i386 sur une Buster avec systemd et udev sans problème. Il y a aucun
problème à changer de noyau.


Bonjour,

	Ça se fait, mais de là à dire sans problème... J'ai dû faire un 
rétrofit de matériel qui avait été installé avec un 4.x (j'ai oublié le 
numéro mineur). Le noyau 3.16 s'installe, boote, mais se baugeait lors 
de l'appel à udev et systemd. Il y a une dépendance forte entre udev, la 
version de la bouse systemd et celle du noyau. Ça peut se passer bien, 
avec juste une ligne de warning ou rien du tout, ça peut aussi mettre le 
système en vrac. On ne peut plus aujourd'hui garder des versions du 
noyau différentes pour se sortir d'un mauvais pas de manière fiable.


	Lorsque tu prends une Debian avec un 4.11 ou 4.12 et que tu veux 
remettre un 3.16, il convient d'installer toutes les dépendances du 
3.16. Et ça peut faire beaucoup de monde puisque de plus en plus 
d'outils tiers dépendent de la saloperie systemd.


	Dans le sens contraire, tu peux _aussi_ avoir des problèmes. Pas plus 
tard qu'hier, j'ai fait un dist-upgrade sur un serveur de test. 
Changement de noyau et, forcément, changement de udev et systemd. 
Impossible à redémarrer sans passer au bouton ! shutdown -r ne faisait 
rien (sauf bouffer 100% d'un CPU durant plus d'une heure). Le noyau 
initial était un 4.11, le nouveau un 4.12 avec la grouille qui venait 
avec lui. Là, ça allait, j'étais à côté de la machine. Mais je sens que 
je vais me déplacer pour mes machines hébergées qui n'ont pas de bandeau 
de prise commandé à distance.


Cordialement,

JKB

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 15:16, Seb a écrit :


Par contre, concernant le choix du noyau 3.16, pourquoi avoir choisi 
celui de wheezy-backports qui était adapté à l'userland de wheezy 
(déjà ancien et sans systemd) et n'est plus maintenu depuis la 
publication de jessie, plutôt que celui de jessie ?


Quand j'ai installé Jessie sur la machine de bureau, en 2015, je n'ai eu 
aucun problème avec le débit des disques.
Quand j'ai installé Jessie sur la machine à la maison, qui est presque 
un clone de la machine de bureau, en janvier 2017, le problème est 
apparu. À la même date, Jessie sur la machine de bureau, sur laquelle je 
fais des 'upgrade' mais jamais de 'dist-upgrade', fonctionnait sans 
problème.
Je fais donc l'hypothèse que le noyau a été mis à jour (sans changement 
du numéro de version) pendant la durée de vie de Jessie.


Je suis dubitatif sur cette hypothèse car un dist-upgrade n'est 
nécessaire pour mettre à jour le noyau qu'en cas de changement d'ABI, 
précisément parce que le nom des paquets du noyau, qui contient la 
version de l'ABI, change. Or d'après ce que je peux voir il n'y a pas eu 
de changement de la version d'ABI (4) du noyau 3.16 inclus dans Jessie 
depuis la publication initiale de Jessie. Donc un simple upgrade était 
suffisant pour installer toutes les mises à jour du noyau jusqu'à ce jour.

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 14:58, Frédéric MASSOT a écrit :


Il y a plusieurs années avec Lilo sur une machine physique où le mode
PAE ne fonctionnait pas bien, je limitais la mémoire à 3,7 ou 3,6 Go en
passant le paramètre mem= au noyau. La machine avait un problème avec le
PCI Hole.


Ce n'était probablement pas le PAE que ne fonctionnait pas bien mais le 
remapping de la mémoire physique masquée par le PCI hole au delà de la 
barrière de 4 Gio (et qui est donc inaccessible en 32 bits sans PAE).

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 13:34, BERTRAND Joël a écrit :

Pascal Hambourg a écrit :

Le 05/10/2017 à 12:51, BERTRAND Joël a écrit :


J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)


 Et en recompilant depuis les sources quitte à recompiler en 32
bits sur un système 64 bits ?


Ou en activant le multi-arch et en installant les bibliothèques 32 bits
nécessaires ?


 Ça coule de source. Mais à force, ledit paquet risque de demander 
des bibliothèques qui ne seront plus sur les versions récentes de debian...


Certes mais si le .deb s'installe sur stretch i386, cela signifie que 
les dépendances nécessaires sont encore disponibles.



 Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau
d'adressé plus de 4Go de mémoire (périphériques compris) au prix d'une
complexité accrue.


Avoir (ou déclarer avec l'option mem=) moins de 4 Go de RAM ne
désactivera pas PAE. C'est une option en dur dans le noyau. Pour
désactiver PAE, je crois qu'il faut un noyau non PAE (ce qui fait perdre
des fonctionnalités comme le NX/XD bit).


 Je pense (mais je n'ai pas regardé, il y a longtemps que je ne 
bidouille plus le noyau Linux) qu'avec moins de 4 Go de mémoire, même 
avec PAE, le système ne va pas essayer de mapper la mémoire sur plus de 
32 bits d'adresses, donc n'essayera pas d'étendre l'adressage au-delà.


D'après ce que j'ai compris en lisant

l'activation de PAE modifie la structure des tables de pages (avec 
notamment un niveau supplémentaire), quelle que soit la quantité de 
mémoire physique à adresser. Je ne pense pas que le fait que la totalité 
de la mémoire physique soit adressable avec 32 bits y change quelque chose.



Par ailleurs, il faut savoir que l'architecture amd64 met en oeuvre un
mécanisme d'adressage à plusieurs niveaux dérivé de PAE.


 Ça ne dépend pas des options de compilation et des scripts 
d'édition des liens ? Il me semble qu'il est possible de forcer la 
taille des pointeurs dans ces scripts. Si tu force un adressage 64 bits 
réels, je ne vois pas ce qu'un mécanisme dérivé de PAE pourra bien venir 
faire là-dedans.


Le point commun, c'est l'utilisation de tables de pages avec des entrées 
sur 64 bits.

Re: Performance RAID instable

[Seb]

(Je vois bien la méthode facile et rapide pour descendre à 4 Go: 
enlever l'une des deux barrettes de RAM; comment feriez-vous si vous ne 
pouviez pas toucher au matériel ?)

En passant l'option mem=xxx à la ligne de commande du noyau.


Donc à la main lors du boot. OK.
(Oui bidouiller /etc/default/grub, noté.)

Par contre, concernant le choix du noyau 3.16, pourquoi avoir choisi 
celui de wheezy-backports qui était adapté à l'userland de wheezy (déjà 
ancien et sans systemd) et n'est plus maintenu depuis la publication de 
jessie, plutôt que celui de jessie ?


Quand j'ai installé Jessie sur la machine de bureau, en 2015, je n'ai eu 
aucun problème avec le débit des disques.
Quand j'ai installé Jessie sur la machine à la maison, qui est presque un 
clone de la machine de bureau, en janvier 2017, le problème est apparu. 
À la même date, Jessie sur la machine de bureau, sur laquelle je fais des 
'upgrade' mais jamais de 'dist-upgrade', fonctionnait sans problème.
Je fais donc l'hypothèse que le noyau a été mis à jour (sans changement du 
numéro de version) pendant la durée de vie de Jessie. Je sais que je ne 
veux pas la version du noyau qui était en vigueur dans Jessie juste avant 
la release de Stretch. Je ne sais pas laquelle des deux versions me 
donnerait le paquet linux-image-3.16.0-4-686-pae. Dans le doute, j'ai pris 
la version la plus ancienne que me proposait apt-get: 
linux-image-3.16.0-0.bpo.4-686-pae . Cela dit, s'il ne parle pas à 
systemd, ça va pas booter en Debian 9...



Seb.

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 14:38, Seb a écrit :


(Je vois bien la méthode facile 
et rapide pour descendre à 4 Go: enlever l'une des deux barrettes de 
RAM; comment feriez-vous si vous ne pouviez pas toucher au matériel ?)


En passant l'option mem=xxx à la ligne de commande du noyau.

Par contre, concernant le choix du noyau 3.16, pourquoi avoir choisi 
celui de wheezy-backports qui était adapté à l'userland de wheezy (déjà 
ancien et sans systemd) et n'est plus maintenu depuis la publication de 
jessie, plutôt que celui de jessie ?

Re: Performance RAID instable

[Frédéric MASSOT]

Le 05/10/2017 à 14:38, Seb a écrit :
> 
>> * Le problème ne se manifeste pas sur deux autres machines sous
>> Debian 9, qui ont pourtant le noyau 4.9.0-3-686-pae, signe que ce
>> n'est pas toute cette classe de noyaux qui pose problème.
> 
> Pardon, correction: je constate que ces deux machines (qui fonctionnent
> bien, elles) ont 2 Go de RAM. Du coup, l'hypothèse d'une RAM > 4 Go mal
> gérée dans les noyaux récents se trouve confortée.
> 
> Sur ma machine de bureau, je dois hélas régulièrement utiliser InDesign
> dans une VirtualBox: ça rame déjà affreusement, ça m'embêterait de ne
> pas disposer de 8 Go quand j'en ai besoin. Sur la machine à la maison,
> par contre, je pourrai sans problème descendre à 4 Go si le passage au
> noyau 3.16 ne se passe pas comme espéré. (Je vois bien la méthode facile
> et rapide pour descendre à 4 Go: enlever l'une des deux barrettes de
> RAM; comment feriez-vous si vous ne pouviez pas toucher au matériel ?)

Merci de ne pas me mettre en copie des mails je suis abonné à la liste.

Il y a plusieurs années avec Lilo sur une machine physique où le mode
PAE ne fonctionnait pas bien, je limitais la mémoire à 3,7 ou 3,6 Go en
passant le paramètre mem= au noyau. La machine avait un problème avec le
PCI Hole.

Aujourd'hui, tu peux ajouter "mem=3072m" à la ligne
"GRUB_CMDLINE_LINUX_DEFAULT=" du fichier "/etc/default/grub". Il faudra
tester avec plusieurs valeurs du seuil de la mémoire.


-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Performance RAID instable

[Seb]

* Le problème ne se manifeste pas sur deux autres machines sous 
Debian 9, qui ont pourtant le noyau 4.9.0-3-686-pae, signe que ce n'est 
pas toute cette classe de noyaux qui pose problème.


Pardon, correction: je constate que ces deux machines (qui fonctionnent 
bien, elles) ont 2 Go de RAM. Du coup, l'hypothèse d'une RAM > 4 Go mal 
gérée dans les noyaux récents se trouve confortée.


Sur ma machine de bureau, je dois hélas régulièrement utiliser InDesign 
dans une VirtualBox: ça rame déjà affreusement, ça m'embêterait de ne pas 
disposer de 8 Go quand j'en ai besoin. Sur la machine à la maison, par 
contre, je pourrai sans problème descendre à 4 Go si le passage au noyau 
3.16 ne se passe pas comme espéré. (Je vois bien la méthode facile et 
rapide pour descendre à 4 Go: enlever l'une des deux barrettes de RAM; 
comment feriez-vous si vous ne pouviez pas toucher au matériel ?)



Seb.

Re: Performance RAID instable

[Seb]

Bonjour,



Tu peux ajouter ces lignes dans le fichier "/etc/apt/sources.list" :
deb ftp://ftp.debian.org/debian/ wheezy-backports main contrib non-free
deb ftp://ftp.fr.debian.org/debian jessie main contrib non-free


Merci ! C'est ce que j'ai fait, Le package que je viens d'installer est
linux-image-3.16.0-0.bpo.4-686-pae
Par contre j'ai fait ça à distance si bien que je ne peux pas sélectionner 
aisément le noyau à utiliser par défaut lors du reboot; je testerai de 
visu ce soir pour valider que le système démarre correctement en 3.16 .



À propos de l'archi:

* Le problème ne se manifeste pas sur deux autres machines sous Debian 9, 
qui ont pourtant le noyau 4.9.0-3-686-pae, signe que ce n'est pas toute 
cette classe de noyaux qui pose problème.


* Avec le noyau initial de la Debian 8 (mais pas avec le noyau qui 
équipait l'ISO en janvier 2017), sur la même machine au bureau je n'avais 
aucun souci (8 Go RAM, noyau -686-pae).



À propos de gqview: oui, théoriquement je pourrais recompiler à partir des 
sources, en gardant des versions figées des bibliothèques, à la manière 
d'un snap. Mais pour l'instant, il suffit que j'accepte la légère pénalité 
de performance d'un noyau -686 par rapport à un noyau -amd pour pouvoir 
utiliser tel quel un ancien .deb; le compromis me va.



Seb.

Re: Performance RAID instable

[Frédéric MASSOT]

Le 05/10/2017 à 11:12, BERTRAND Joël a écrit :
> Seb a écrit :
>>
>> Bonjour Pascal,
>>
>>
>>> Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait
>>> : utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?
>>
>> Ah oui, c'est une bonne idée.
>>
>> Si j'appelle sur une machine en Debian 9
>>     apt-cache search linux-image
>> je ne vois pas de noyau 3.16 .
>>
>> Dans la FAQ Debian, chapitre "Debian and the kernel", je ne vois pas de
>> solution packagée indiquée; d'un autre côté, elle ne mentionne pas non
>> plus les backports pour avoir, au contraire, un noyau plus récent.
>>
>> Y a-t-il une méthode standard Debian qui me permettrait d'installer sans
>> trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne
>> page web m'irait amplement.)
> 
> Avec un init systemV, c'est assez trivial. Avec la grouille
> systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire
> ça, cela s'est soldé par un échec.

À cause du bug (865866) de LibreOffice Writer j'utilise un noyau 3.16
i386 sur une Buster avec systemd et udev sans problème. Il y a aucun
problème à changer de noyau.


-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Performance RAID instable

[BERTRAND Joël]

Pascal Hambourg a écrit :

Le 05/10/2017 à 12:51, BERTRAND Joël a écrit :



Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).


J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)


 Et en recompilant depuis les sources quitte à recompiler en 32
bits sur un système 64 bits ?


Ou en activant le multi-arch et en installant les bibliothèques 32 bits
nécessaires ?


	Ça coule de source. Mais à force, ledit paquet risque de demander des 
bibliothèques qui ne seront plus sur les versions récentes de debian...



Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée


8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement
(VirtualBox).


 Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau
d'adressé plus de 4Go de mémoire (périphériques compris) au prix d'une
complexité accrue.


Avoir (ou déclarer avec l'option mem=) moins de 4 Go de RAM ne
désactivera pas PAE. C'est une option en dur dans le noyau. Pour
désactiver PAE, je crois qu'il faut un noyau non PAE (ce qui fait perdre
des fonctionnalités comme le NX/XD bit).


	Je pense (mais je n'ai pas regardé, il y a longtemps que je ne 
bidouille plus le noyau Linux) qu'avec moins de 4 Go de mémoire, même 
avec PAE, le système ne va pas essayer de mapper la mémoire sur plus de 
32 bits d'adresses, donc n'essayera pas d'étendre l'adressage au-delà.



Par ailleurs, il faut savoir que l'architecture amd64 met en oeuvre un
mécanisme d'adressage à plusieurs niveaux dérivé de PAE.


	Ça ne dépend pas des options de compilation et des scripts d'édition 
des liens ? Il me semble qu'il est possible de forcer la taille des 
pointeurs dans ces scripts. Si tu force un adressage 64 bits réels, je 
ne vois pas ce qu'un mécanisme dérivé de PAE pourra bien venir faire 
là-dedans.


Cordialement,

JKB

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 12:51, BERTRAND Joël a écrit :



    Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).


J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)


 Et en recompilant depuis les sources quitte à recompiler en 32 bits 
sur un système 64 bits ?


Ou en activant le multi-arch et en installant les bibliothèques 32 bits 
nécessaires ?



    Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée


8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).


 Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de 
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau d'adressé 
plus de 4Go de mémoire (périphériques compris) au prix d'une complexité 
accrue.


Avoir (ou déclarer avec l'option mem=) moins de 4 Go de RAM ne 
désactivera pas PAE. C'est une option en dur dans le noyau. Pour 
désactiver PAE, je crois qu'il faut un noyau non PAE (ce qui fait perdre 
des fonctionnalités comme le NX/XD bit).
Par ailleurs, il faut savoir que l'architecture amd64 met en oeuvre un 
mécanisme d'adressage à plusieurs niveaux dérivé de PAE.

Re: Performance RAID instable

[BERTRAND Joël]

Seb a écrit :


Bonjour,



Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).


J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)


	Et en recompilant depuis les sources quitte à recompiler en 32 bits sur 
un système 64 bits ?



Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée


8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).


	Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de 
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau d'adressé 
plus de 4Go de mémoire (périphériques compris) au prix d'une complexité 
accrue.



et le chipset (ou le contrôleur disque). C'est un point à ne pas
négliger d'autant que je vois pae dans le nom du noyau.


Je ne sais pas comment trouver le nom du chipset; peux-tu m'indiquer
quelle serait la bonne commande ?


lspci par exemple.


  Avec un init systemV, c'est assez trivial. Avec la grouille
systemd/udev, c'est assez casse-gueule.


J'aurais préféré rester en systemV, mais l'option n'est pas proposée
lors de l'installation de Debian et je ne sais pas dans quelle mesure on
peut espérer que Devuan et Debian resteront synchrones.


La seule fois où j'ai dû faire ça, cela s'est soldé par un échec.


Aïe...


Bien cordialement,

JKB

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 11:12, BERTRAND Joël a écrit :

Seb a écrit :


Y a-t-il une méthode standard Debian qui me permettrait d'installer sans
trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne
page web m'irait amplement.)


 Avec un init systemV, c'est assez trivial. Avec la grouille 
systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire 
ça, cela s'est soldé par un échec.


Je l'avais fait quand Debian 9 stretch était encore en testing, peu 
avant sa publication en stable. Pas de problème particulier, sauf avec 
le GPU Radeon : en l'absence du firmware pourtant optionnel avec ce 
modèle de GPU, l'initialisation du module radeon semblait ne pas aller à 
son terme (il manquait des messages dans les logs du noyau) et 
l'affichage se coupait. Pourtant le même noyau 3.16 initialisait 
correctement le GPU même sans firmware avec le userland de Debian 8 
jessie. Le dernier message du module radeon dans les logs du noyau 
parlant de "user helper", il se peut fort bien que ce soit effectivement 
une incompatibilité avec la version de systemd/udev de stretch. Aucun 
problème en revanche si le firmware était présent, ni avec le noyau 4.9 
de stretch avec ou sans firmware.

Re: Performance RAID instable

[Frédéric MASSOT]

Le 05/10/2017 à 11:27, Seb a écrit :
> 
> Bonjour,
> 
> 
>> Une remarque en passant : je n'ai pas observé ce genre de chose en
>> amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).
> 
> J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
> visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
> effacer des images si je laisse la touche Delete appuyée, ce qui
> m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
> un .deb mais il ne s'installe pas sur un système en 64 bits.)
> 
>> Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
>> installée
> 
> 8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).
> 
>> et le chipset (ou le contrôleur disque). C'est un point à ne pas
>> négliger d'autant que je vois pae dans le nom du noyau.
> 
> Je ne sais pas comment trouver le nom du chipset; peux-tu m'indiquer
> quelle serait la bonne commande ?

Tu peux utiliser lspci ou lshw.



-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Performance RAID instable

[Seb]

Bonjour,


	Une remarque en passant : je n'ai pas observé ce genre de chose en 
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).


J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le 
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien 
effacer des images si je laisse la touche Delete appuyée, ce qui m'arrive 
souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé un .deb 
mais il ne s'installe pas sur un système en 64 bits.)


	Je ne sais pas si tu as indiqué plus haut la taille de la mémoire 
installée


8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).

et le chipset (ou le contrôleur disque). C'est un point à ne pas 
négliger d'autant que je vois pae dans le nom du noyau.


Je ne sais pas comment trouver le nom du chipset; peux-tu m'indiquer 
quelle serait la bonne commande ?



  Avec un init systemV, c'est assez trivial. Avec la grouille
systemd/udev, c'est assez casse-gueule.


J'aurais préféré rester en systemV, mais l'option n'est pas proposée lors 
de l'installation de Debian et je ne sais pas dans quelle mesure on peut 
espérer que Devuan et Debian resteront synchrones.



La seule fois où j'ai dû faire ça, cela s'est soldé par un échec.


Aïe...


Seb.

Re: Performance RAID instable

[BERTRAND Joël]

Seb a écrit :


Bonjour Pascal,



Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait
: utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?


Ah oui, c'est une bonne idée.

Si j'appelle sur une machine en Debian 9
apt-cache search linux-image
je ne vois pas de noyau 3.16 .

Dans la FAQ Debian, chapitre "Debian and the kernel", je ne vois pas de
solution packagée indiquée; d'un autre côté, elle ne mentionne pas non
plus les backports pour avoir, au contraire, un noyau plus récent.

Y a-t-il une méthode standard Debian qui me permettrait d'installer sans
trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne
page web m'irait amplement.)


	Avec un init systemV, c'est assez trivial. Avec la grouille 
systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire 
ça, cela s'est soldé par un échec.


JKB

Re: Performance RAID instable

[BERTRAND Joël]

Seb a écrit :


Bonjour,



Pour finir, je sais obtenir un retour a des performances normales en
vidant le cache :
sync ; echo 2 > /proc/sys/vm/drop_caches
et comme toi, j'ai une nouvelle dégradation violente au bout d'un
certain temps.


Il y a quelques jours, j'ai passé la machine à la maison (Debian 9
stable) sur le noyau 4.12.0-0.bpo.1-686-pae (backports). J'ai continué à
mesurer la performance des disques avec cette nouvelle situation. Voici
le résultat:
https://framapic.org/bFa8E3Zz3aJA/3vFMDsmo5LhF.png


Bon...

	Une remarque en passant : je n'ai pas observé ce genre de chose en 
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).


	Je ne sais pas si tu as indiqué plus haut la taille de la mémoire 
installée et le chipset (ou le contrôleur disque). C'est un point à ne 
pas négliger d'autant que je vois pae dans le nom du noyau.


Cordialement,

JKB

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 10:40, Pascal Hambourg a écrit :


Sinon, faire comme avec les backports : ajouter les dépôts jessie dans 
sources.list et forcer l'installation du paquet de jessie avec apt-get 
-t jessie...


En fait même pas besoin de forcer puisque le paquet n'existe pas dans 
stretch.

Re: Performance RAID instable

[Frédéric MASSOT]

Le 05/10/2017 à 10:24, Seb a écrit :
> 
> Bonjour Pascal,
> 
> 
>> Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait
>> : utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?
> 
> Ah oui, c'est une bonne idée.
> 
> Si j'appelle sur une machine en Debian 9
> apt-cache search linux-image
> je ne vois pas de noyau 3.16 .

Les versions 3.16 sont dans les wheezy-backports et chez jessie :

https://packages.debian.org/search?suite=all=all=any=names=linux-image-3.16

Tu peux ajouter ces lignes dans le fichier "/etc/apt/sources.list" :

deb ftp://ftp.debian.org/debian/ wheezy-backports main contrib non-free
deb ftp://ftp.fr.debian.org/debian jessie main contrib non-free


Tu peux aussi ajouter l'ensemble des dépôts Wheezy et Jessie :

deb http://ftp.fr.debian.org/debian/ wheezy main contrib non-free
deb http://ftp.fr.debian.org/debian/ wheezy-updates main contrib non-free
deb http://security.debian.org/ wheezy/updates main contrib non-free
deb http://ftp.debian.org/debian/ wheezy-backports main contrib non-free

deb http://ftp.fr.debian.org/debian jessie main contrib non-free
deb http://security.debian.org/ jessie/updates main contrib non-free
deb http://ftp.fr.debian.org/debian jessie-updates main contrib non-free
deb http://ftp.fr.debian.org/debian/ jessie-backports main contrib non-free



-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 10:24, Seb a écrit :


Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait 
: utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?

(...)
Y a-t-il une méthode standard Debian qui me permettrait d'installer sans 
trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne 
page web m'irait amplement.)


J'essaierais de récupérer directement le .deb du noyau 3.16 de Jessie 
depuis  
(je suppose que l'architecture est amd64) ou depuis une machine sous 
Jessie avec apt-get download et de l'installer avec dpkg -i sur Stretch. 
Les dépendances devraient être satisfaites.


Sinon, faire comme avec les backports : ajouter les dépôts jessie dans 
sources.list et forcer l'installation du paquet de jessie avec apt-get 
-t jessie...

Re : Performance RAID instable

[Seb]

Bonjour Thierry,


Idée de troisième solution à faire en parallèle d'un contournement: se 
rapprocher des développeurs du kernel pour signaler qu'il y a 
probablement un bug. Je pense qu'il n'y pas plus vraiment de doute 
l'existence d'un bug. Peut être que eux, justement, pourront proposer un 
contournement fiable en attendant la release du correctif.


C'est faisable. Tu me conseilles de contacter debian-kernel ou lkml ?


Seb.

Re: Performance RAID instable

[Seb]

Bonjour Pascal,


Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait : 
utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?


Ah oui, c'est une bonne idée.

Si j'appelle sur une machine en Debian 9
apt-cache search linux-image
je ne vois pas de noyau 3.16 .

Dans la FAQ Debian, chapitre "Debian and the kernel", je ne vois pas de 
solution packagée indiquée; d'un autre côté, elle ne mentionne pas non 
plus les backports pour avoir, au contraire, un noyau plus récent.


Y a-t-il une méthode standard Debian qui me permettrait d'installer sans 
trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne 
page web m'irait amplement.)


Il y a bien longtemps de cela, dans les années 1990, je compilais mes 
noyaux à la main; ensuite il y a eu trop d'options dans le noyau pour que 
cela reste raisonnable (et puis il fallait aussi s'occuper d'initramfs, 
puis grub a supplanté lilo), bref par commodité je n'ai plus utilisé que 
le noyau pré-packagé depuis une quinzaine d'années. Faute d'expérience 
récente, j'aimerais bien éviter de replonger les mains trop profondément 
dans le système, sans outils Debian dédiés il est presque sûr que 
j'obtiendrais au mieux une machine qui ne boote plus.



Seb.

Re: Performance RAID instable

[Pascal Hambourg]

Le 04/10/2017 à 21:13, Seb a écrit :


Il me reste donc deux options:

* Effacer la Debian 9, installer une Debian 8 qui, elle, n'avait pas ce 
problème.


* Appeler en crontab chaque heure le contournement ponctuel de 
Jean-Bernard.


La deuxième solution est crado, mais je ne connais pas ses vrais 
inconvénients (risques de plantage ?). Les connaissez-vous ?


L'inconvénient, c'est l'effet pour lequel elle a été conçue : le vidage 
du cache des méta-données des systèmes de fichiers, obligeant le noyau à 
relire ces méta-données depuis les disques en cas de besoin. Avec des 
SSD, l'impact négatif doit être moins sensible.



Et entre les deux, que me conseillez-vous ?


Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait : 
utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?

Re : Performance RAID instable

[Thierry Bugier]

Bonjour

Le mercredi 04 octobre 2017 à 21:13 +0200, Seb a écrit :
> 
> Il me reste donc deux options:
> 
> * Effacer la Debian 9, installer une Debian 8 qui, elle, n'avait pas
> ce 
> problème.
> 
> * Appeler en crontab chaque heure le contournement ponctuel de 
> Jean-Bernard.
> 
> La deuxième solution est crado, mais je ne connais pas ses vrais 
> inconvénients (risques de plantage ?). Les connaissez-vous ?
> 
> Et entre les deux, que me conseillez-vous ?
> 
> Une idée pour une troisième option ? (À part bug-fixer le noyau :-)
> 

Idée de troisième solution à faire en parallèle d'un contournement: se
rapprocher des développeurs du kernel pour signaler qu'il y a
probablement un bug. Je pense qu'il n'y pas plus vraiment de doute
l'existence d'un bug. Peut être que eux, justement, pourront proposer
un contournement fiable en attendant la release du correctif.

> 
> Seb.

Re: Performance RAID instable

[Seb]

Bonjour,


Pour finir, je sais obtenir un retour a des performances normales en vidant 
le cache :

sync ; echo 2 > /proc/sys/vm/drop_caches
et comme toi, j'ai une nouvelle dégradation violente au bout d'un certain 
temps.


Il y a quelques jours, j'ai passé la machine à la maison (Debian 9 stable) 
sur le noyau 4.12.0-0.bpo.1-686-pae (backports). J'ai continué à mesurer 
la performance des disques avec cette nouvelle situation. Voici le 
résultat:

https://framapic.org/bFa8E3Zz3aJA/3vFMDsmo5LhF.png

J'observe ceci:

* La vitesse normale de la partition mesurée (par un simple 'dd') est 
d'environ 1000 Mo/s. Cette vitesse est atteinte si j'appelle à la main la 
commande envoyée par Jean-Bernard:

sync; echo 2 >! /proc/sys/vm/drop_caches

* Le système n'est toujours pas stable à cette vitesse, mais quand le 
débit chute, après quelques heures seulement, il peut se stabiliser vers 
150 Mo/s (1er octobre) ou (comme avant) à < 1 Mo/s (4 octobre). La chute 
est toujours aussi brutale.


* Au régime intermédiaire 150 Mo/s, le système finit par retomber 
spontanément au régime bas < 1 Mo/s.


* Dans les minutes qui suivent minuit, auparavant quelque chose dans le 
système (dans le noyau ?) envoyait la machine en régime bas; maintenant, 
cette même chose la remet en régime intermédiaire si elle se trouvait en 
régime bas (2-3 octobre) mais aussi si elle se trouvait en régime haut 
(1-2 octobre, 3-4 octobre).


* Aujourd'hui, tout à droite de la courbe, je constate une oscillation 
entre régime haut et régime intermédiaire. Je n'ai pas été devant la 
machine de toute la journée.



Hypothèses:

* Puisque le changement de noyau produit un changement de comportement, on 
peut supposer que le problème est dans le noyau, ou du moins lié au noyau.


* On dirait que le programme qui s'enclenche peu après minuit cherche à 
régler le débit sur un régime qu'il estime soutenable à moyen terme. 
(Rappel: c'est du RAID1 sur deux disques SSD modernes, il devrait sans 
problème pouvoir tenir 1000 Mo/s.) Signe peut-être que des développeurs 
ont eu conscience d'un problème et qu'ils ont cherché à amenuiser ses 
conséquences, sans résoudre vraiment la question de fond cependant.



À ce stade, je me suis dit qu'il serait judicieux d'installer le tout 
dernier noyau mais... c'est le 4.12 en fait, celui que j'ai mis il y a 
quelques jours.


Il me reste donc deux options:

* Effacer la Debian 9, installer une Debian 8 qui, elle, n'avait pas ce 
problème.


* Appeler en crontab chaque heure le contournement ponctuel de 
Jean-Bernard.


La deuxième solution est crado, mais je ne connais pas ses vrais 
inconvénients (risques de plantage ?). Les connaissez-vous ?


Et entre les deux, que me conseillez-vous ?

Une idée pour une troisième option ? (À part bug-fixer le noyau :-)


Seb.

Re: Performance RAID instable

[Pascal Hambourg]

Le 28/09/2017 à 17:46, Seb a écrit :


si des tests de débit comparatifs pour déterminer l'étendue 
précise du problème avaient été faits :

- en lecture dans le système de fichiers


Non testé.


- en écriture dans le système de fichiers


Testé.


- en lecture brute dans le périphérique bloc
- en écriture brute dans le périphérique bloc (attention : détruit le 
système de fichiers)


Pas testé :-)


- même chose dans une partition classique non RAID


Testé en écriture (pas par moi): pareil.


- même chose avec d'autres types de systèmes de fichiers


Non testé.

Quelles informations rechercherait-on avec ces tests supplémentaires ?


Déterminer quels sont les facteurs qui impactent les performances.

Re: Performance RAID instable

[Seb]

Bonjour Pascal,


Plus exactement, la valeur 2 ne vide que les caches de "dentries" 
(directory entries) et d'inodes, c'est-à-dire les méta-données associées 
aux répertoires et fichiers, mais pas le cache du contenu des fichiers.


Merci pour la correction.

L'information m'a peut-être échappée, mais je n'ai pas vu dans les messages 
si des tests de débit comparatifs pour déterminer l'étendue précise du 
problème avaient été faits :

- en lecture dans le système de fichiers


Non testé.


- en écriture dans le système de fichiers


Testé.


- en lecture brute dans le périphérique bloc
- en écriture brute dans le périphérique bloc (attention : détruit le système 
de fichiers)


Pas testé :-)


- même chose dans une partition classique non RAID


Testé en écriture (pas par moi): pareil.


- même chose avec d'autres types de systèmes de fichiers


Non testé.

Quelles informations rechercherait-on avec ces tests supplémentaires ?


Seb.

Re: Re : Re : Performance RAID instable

[Seb]

Bonjour,


Donc c'est clair (et d'autres messages le confirment) que ce n'est pas 
lié à la nature des disques.


(Ni au système de fichiers.)

Vu la solution de contournement, ca doit se passer au niveau de la 
gestion du cache en RAM.


Ça semble sensé.
Je viens d'installer un noyau 4.12 (686-pae) avec stretch-backport, on 
verra si cela change quelque chose...



Seb.

Re : Re : Performance RAID instable

[Thierry Bugier]

Bonjour

Le jeudi 28 septembre 2017 à 08:59 +0200, Jean-Bernard Dubois a écrit :
> Le 26/09/2017 à 16:40, Thierry Bugier a écrit :
> > Bonjour
> > 
> > Le mardi 26 septembre 2017 à 15:55 +0200, Jean-Bernard Dubois a
> > écrit :
> > > J'ai également constaté un comportement très similaire sur un de
> > > mes
> > > serveurs après le passage a debian9. J'ai également incriminé le
> > > raid
> > > (raid5 hard HP).
> > > Mais après plusieurs essais, je constate que le même phénomène se
> > > produit aussi sur le disque amovible USB3 qui est sur la même
> > > machine.
> > 
> > Sur ce type de RAID, j'imagine que ce sont des disques magnétiques,
> > n'est ce pas ?
> > 
> > 
> 
> Oui. Et le disque amovible est aussi a plateaux et pas du tout en
> raid.
> 

Donc c'est clair (et d'autres messages le confirment) que ce n'est pas
lié à la nature des disques. 

Je n'ai pas pu réfléchir encore aux graphes de performance délivrés
hier. Peut être ce soir. 

Si un disque en USB3 (non RAID) pose également le souci je crois que le
code du RAID logiciel n'est pas en cause, et que ça se passe ailleurs.
Vu la solution de contournement, ca doit se passer au niveau de la
gestion du cache en RAM.

Re: Performance RAID instable

[BERTRAND Joël]

Jean-Bernard Dubois a écrit :

Le 27/09/2017 à 13:00, Seb a écrit :


Bonjour,



J'ai également constaté un comportement très similaire sur un de mes
serveurs après le passage a debian9.


Merci de le dire !


J'ai également incriminé le raid (raid5 hard HP).


Sur disques SSD ou à plateaux ?
Avec quel filesystem ?

A plateaux, ext4



Bonjour,

Avec Buster, je ne note pas ce genre de désagrément. ext3 et ext4 sur 
raid1 et rai6d tout en magnétique (machine avec un i7 et 16 Go de mémoire).


Noyau courant : 4.12.0-1-amd64

En revanche, sur un portable avec 4Go de mémoire (et un core2duo), j'ai 
régulièrement avec ce même noyau le passage de oom-killer, ce que je 
n'avais jamais avant lui. Je pense qu'il y a un problème plus général 
qu'un problème raid avec ce noyau.


Cordialement,

JKB

Re: Performance RAID instable

[Jean-Bernard Dubois]

Le 27/09/2017 à 13:00, Seb a écrit :


Bonjour,


J'ai également constaté un comportement très similaire sur un de mes 
serveurs après le passage a debian9.


Merci de le dire !


J'ai également incriminé le raid (raid5 hard HP).


Sur disques SSD ou à plateaux ?
Avec quel filesystem ?

A plateaux, ext4

--
Cordialement
Jean-Bernard Dubois
Gaïa Converter

Re: Re : Performance RAID instable

[Jean-Bernard Dubois]

Le 26/09/2017 à 16:40, Thierry Bugier a écrit :

Bonjour

Le mardi 26 septembre 2017 à 15:55 +0200, Jean-Bernard Dubois a écrit :

J'ai également constaté un comportement très similaire sur un de mes
serveurs après le passage a debian9. J'ai également incriminé le
raid
(raid5 hard HP).
Mais après plusieurs essais, je constate que le même phénomène se
produit aussi sur le disque amovible USB3 qui est sur la même
machine.

Sur ce type de RAID, j'imagine que ce sont des disques magnétiques,
n'est ce pas ?



Oui. Et le disque amovible est aussi a plateaux et pas du tout en raid.

--

Cordialement
Jean-Bernard Dubois
Gaïa Converter

Re: Performance RAID instable

[Pascal Hambourg]

Le 27/09/2017 à 13:00, Seb a écrit :


Pour finir, je sais obtenir un retour a des performances normales en 
vidant le cache :

sync ; echo 2 > /proc/sys/vm/drop_caches

(...)
J'ai utilisé "/proc/sys/vm/drop_caches" comme mot-clef dans Google. La 
ligne de commande que tu indiques demande au noyau de libérer la RAM 
qu'il avait allouée pour mettre en cache les fichiers et répertoires 
qu'il a lus.


Plus exactement, la valeur 2 ne vide que les caches de "dentries" 
(directory entries) et d'inodes, c'est-à-dire les méta-données associées 
aux répertoires et fichiers, mais pas le cache du contenu des fichiers.


La valeur affichée dans la colonne "cache" par la commande free ne prend 
en compte que le cache du contenu des fichiers, le "pagecache" et pas 
les caches de dentries et d'inodes. Le pagecache est vidé par la valeur 
1. La valeur 3 vide les deux.


C'est très bizarre que ceci influence la vitesse de nos 
tableaux RAID car cette portion de RAM est supposée être réutilisable 
dès qu'un besoin réel se présente.


Et surtout, ces structures de données sont liées aux systèmes de 
fichiers montés et non aux périphériques bloc tels que les disques ou 
ensembles RAID.


En outre, sur une machine qui est 
actuellement coincée à des débits de 1 Mo/s, j'ai:


~>free -m
   total    used    free  shared  buff/cache   
available

Mem:   7980 773    6125 172    1080   6278
Swap:  3813   0    3813

Sur 8 Go de RAM, plus de 6 Go sont disponibles. On ne peut pas qu'il y 
ait un manque.


Pour information, la mémoire occupée par les caches de dentries et 
d'inodes est comptée dans la colonne "used". Elle fait partie du "slab", 
dont on peut voir la taille dans /proc/meminfo et le détail dans 
/proc/slabinfo (chercher les colonnes contenant "inode" et "dentry").


L'information m'a peut-être échappée, mais je n'ai pas vu dans les 
messages si des tests de débit comparatifs pour déterminer l'étendue 
précise du problème avaient été faits :

- en lecture dans le système de fichiers
- en écriture dans le système de fichiers
- en lecture brute dans le périphérique bloc
- en écriture brute dans le périphérique bloc (attention : détruit le 
système de fichiers)

- même chose dans une partition classique non RAID
- même chose avec d'autres types de systèmes de fichiers

Re: Performance RAID instable

[Seb]

Bonjour,


J'ai également constaté un comportement très similaire sur un de mes 
serveurs après le passage a debian9.


Merci de le dire !


J'ai également incriminé le raid (raid5 hard HP).


Sur disques SSD ou à plateaux ?
Avec quel filesystem ?

Pour finir, je sais obtenir un retour a des performances normales en vidant 
le cache :

sync ; echo 2 > /proc/sys/vm/drop_caches


Super, merci pour cette astuce; je l'ai testée tout à l'heure, elle 
fonctionne aussi chez moi. C'est déjà un soulagement de ne plus avoir à 
rebooter... Même si cela soigne les symptômes sans s'attaquer à la racine 
du problème.


En espérant avoir apporté un élément nouveau qui puisse aider a 
comprendre, je suis moi aussi avide d'une solution.


J'ai utilisé "/proc/sys/vm/drop_caches" comme mot-clef dans Google. La 
ligne de commande que tu indiques demande au noyau de libérer la RAM qu'il 
avait allouée pour mettre en cache les fichiers et répertoires qu'il a 
lus. C'est très bizarre que ceci influence la vitesse de nos tableaux RAID 
car cette portion de RAM est supposée être réutilisable dès qu'un besoin 
réel se présente. En outre, sur une machine qui est actuellement coincée à 
des débits de 1 Mo/s, j'ai:


~>free -m
  totalusedfree  shared  buff/cache   available
Mem:   7980 7736125 1721080   6278
Swap:  3813   03813

Sur 8 Go de RAM, plus de 6 Go sont disponibles. On ne peut pas qu'il y ait 
un manque.


Par ailleurs, j'ai suivi le conseil donné par Thierry Bugier: dans la 
machine à la maison, j'ai branché deux disques à plateaux que j'avais 
remisés, assemblé un RAID1 pour faire une partition (10 Go, JFS, aucun 
fichier) et j'ai enregistré leur débit. J'ai uploadé sur framapic deux 
images parlantes:


Bureau:
https://framapic.org/gallery#Pn5Jx4AuzmI3/5cUOEH82OcpU.png

Maison:
https://framapic.org/mt5DVGNW6QXb/lWj5EGz6jZJ6.png

Elles représentent le débit, mesuré grossièrement avec 'dd', de la 
partition montée en racine, de la partition montée en /home et, pour la 
machine à la maison, de la partition construite avec les disques à 
plateaux. (L'excellent débit des disques à plateaux est dû à la petite 
taille -- 10 Mo -- du fichier que je crée avec 'dd': on reste dans les 
caches des disques.)


On observe d'abord une excellente concordance des performances: elles 
chutent en même temps sur des filesystems différents. Ce n'est donc pas, 
par exemple, un problème de fsck. En outre, ce n'est pas lié aux disques 
SSD puisque la partition sur les disques à plateaux montre les mêmes 
symptômes.


Je constate aussi une chute dans le premier quart d'heure après minuit 
pour toutes les partitions (2 au bureau, 3 à la maison). Or je n'ai aucune 
crontab, en utilisateur ou en root, qui se lance dans cette tranche 
horaire, sur aucune des deux machines.


Cela pointe vers une action du système juste après minuit. Quand je 
regarde /etc/crontab, cependant, je vois que les cron.daily sont lancées à 
6h25 le matin. Est-ce que quelqu'un a une idée pour identifier ce qui se 
passe peu après minuit dans la Debian ?


Pour continuer les tests, je viens de passer en ext4 la partition des 
disques à plateaux, on verra si elle continue à suivre les autres...



Merci pour votre aide.
Seb.

Re : Performance RAID instable

[Thierry Bugier]

Bonjour

Le mardi 26 septembre 2017 à 15:55 +0200, Jean-Bernard Dubois a écrit :
> J'ai également constaté un comportement très similaire sur un de mes 
> serveurs après le passage a debian9. J'ai également incriminé le
> raid 
> (raid5 hard HP).
> Mais après plusieurs essais, je constate que le même phénomène se 
> produit aussi sur le disque amovible USB3 qui est sur la même
> machine.

Sur ce type de RAID, j'imagine que ce sont des disques magnétiques,
n'est ce pas ?

Re: Performance RAID instable

[Jean-Bernard Dubois]

Le 22/09/2017 à 12:22, Seb a écrit :


Bonjour !

Bonjour



J'utilise Debian depuis une quinzaine d'années, sans problème de RAID 
jusqu'à présent. Mon souci actuel est que deux machines qui font 
chacune du RAID1 sur deux disques SSD ont des performances disque qui 
se dégradent brutalement, sans raison apparente (rien trouvé dans 
syslog, notamment). La vitesse du tableau passe, en gros, de 600 Mo/s 
à 0,5 Mo/s. La différence est si nette qu'une mesure grossière avec 
'dd' suffit à la mettre en évidence (dd if=/dev/zero of=dd.big bs=1k 
count=1).
J'ai également constaté un comportement très similaire sur un de mes 
serveurs après le passage a debian9. J'ai également incriminé le raid 
(raid5 hard HP).
Mais après plusieurs essais, je constate que le même phénomène se 
produit aussi sur le disque amovible USB3 qui est sur la même machine.


Pour finir, je sais obtenir un retour a des performances normales en 
vidant le cache :

sync ; echo 2 > /proc/sys/vm/drop_caches
et comme toi, j'ai une nouvelle dégradation violente au bout d'un 
certain temps.


Comme toi j'utilise Debian depuis longtemps et je n'ai jamais eu de pb 
de disques ou de Raid. Je suis donc totalement ignorant sur le domaine 
et je ne sais pas expliquer ce qui ce passe.
En espérant avoir apporté un élément nouveau qui puisse aider a 
comprendre, je suis moi aussi avide d'une solution.


--
Cordialement
Jean-Bernard Dubois
Gaïa Converter

Re : Performance RAID instable

[Thierry Bugier]

Bonjour

Le dimanche 24 septembre 2017 à 15:42 +0200, Seb a écrit :
> Bonjour,
> 
> 
> >> Je serais fort surpris que le problème soit lié aux disques:
> >> 
> >> * un reboot résout le problème pour plusieurs heures;
> >> 
> >> * ces disques fonctionnaient parfaitement juste avant le passage
> en 
> >> Debian 9, et incorrectement juste après;
> >
> > Tu as essayé avec d'autres versions du noyau ?
> 
> En un sens oui, puisque le problème est apparu sur une machine avec 
> l'installation de la Debian 8, version de janvier 2017, et sur
> l'autre 
> avec l'installation de la Debian 9. Sauf erreur, le noyau n'est pas
> le 
> même dans la Debian 8 de janvier 2017 et dans la Debian 9 de juillet
> 2017.
> 
> 

Pour info je suis avec Debian Sid et j'ai un RAID 1 ainsi qu'un RAID 0
sur 2 paires de disques magnétiques. Pour être précis voici leur
empilement (si je puis dire):
Disques durs / RAID / LVM / systèmes de fichiers

Aucun souci constaté niveau performances et le RAID 1. Si il y a bug,
alors il est peut être en lien avec le fait que les disques de Seb
soient en SSD.

Ca me fait venir une idée : monter un RAID 1 sur disques magnétiques
avec quelques Go de données, puis utiliser un logiciel quelconque pour
lire ou même écrire dessus. Ce serait intéressant de voir si les
performances finissent par chuter. Le but serait de voir si oui ou non
la technologie des disques est déterminante pour faire apparaître le
souci.

H.S.: dans mes brèves recherches sur ce problème, je suis tombé sur
autre chose d'assez intéressant : un raid 1 hybride HDD / SSD pour
avoir un RAID 1 performant sans se ruiner avec 2 SSD.

https://www.bibinsa.net/post/2015/02/16/Hybrid-RAID-SSD-HDD-avec-Linux

Je sens que je vais essayer.

> 
> Seb.

Re: Performance RAID instable

[bernard . schoenacker]

- Mail original -
> De: "Seb" <s...@h-k.fr>
> À: "Frederic MASSOT" <frede...@juliana-multimedia.com>
> Cc: debian-user-french@lists.debian.org
> Envoyé: Dimanche 24 Septembre 2017 15:42:25
> Objet: Re: Performance RAID instable
> 
> 
> Bonjour,
> 
> 
> >> Je serais fort surpris que le problème soit lié aux disques:
> >> 
> >> * un reboot résout le problème pour plusieurs heures;
> >> 
> >> * ces disques fonctionnaient parfaitement juste avant le passage
> >> en
> >> Debian 9, et incorrectement juste après;
> >
> > Tu as essayé avec d'autres versions du noyau ?
> 
> En un sens oui, puisque le problème est apparu sur une machine avec
> l'installation de la Debian 8, version de janvier 2017, et sur
> l'autre
> avec l'installation de la Debian 9. Sauf erreur, le noyau n'est pas
> le
> même dans la Debian 8 de janvier 2017 et dans la Debian 9 de juillet
> 2017.
> 
> 
> Au fait, je voulais vous envoyer un graphique qui montre le débit du
> tableau RAID sur une période de 24 h, mais mon courrier n'atteint
> jamais
> la liste quand il contient une pièce jointe (j'ai essayé les formats
> PDF
> et JPEG). Quelle serait la bonne manière de procéder ?
> 
> 
> Seb.
> 
bonjour,

tu déposes ton image sur framadrop ou framapic et tu donnes
 le lien dans le courriel 


slt
bernard

Re: Performance RAID instable

[Seb]

Bonjour,



Je serais fort surpris que le problème soit lié aux disques:

* un reboot résout le problème pour plusieurs heures;

* ces disques fonctionnaient parfaitement juste avant le passage en 
Debian 9, et incorrectement juste après;


Tu as essayé avec d'autres versions du noyau ?


En un sens oui, puisque le problème est apparu sur une machine avec 
l'installation de la Debian 8, version de janvier 2017, et sur l'autre 
avec l'installation de la Debian 9. Sauf erreur, le noyau n'est pas le 
même dans la Debian 8 de janvier 2017 et dans la Debian 9 de juillet 2017.



Au fait, je voulais vous envoyer un graphique qui montre le débit du 
tableau RAID sur une période de 24 h, mais mon courrier n'atteint jamais 
la liste quand il contient une pièce jointe (j'ai essayé les formats PDF 
et JPEG). Quelle serait la bonne manière de procéder ?



Seb.

Re: Performance RAID instable

[Frederic MASSOT]

Le 22/09/2017 à 17:09, Seb a écrit :


Bonjour,


Les astuces que j'ai décrites permettent de maintenir les performances 
quand on écrit une grande quantité de données d'un coup ou bien une 
grandes quantité d'écritures aléatoirement réparties. C'est donné au 
cas où l'hypothèse que j'ai émise est la bonne, car ça colle très bien 
à ce que j'observe sur les supports amovibles. Reste à vérifier si 
l'architecture dont j'ai parlé est la même sur les SSD. J'irai jeter 
un oeil par curiosité.


La comparaison me paraît limitée: sur mon système, je peux copier des 
centaines de Mo sans aucun problème à pleine vitesse puis, une heure 
plus tard, alors qu'il ne se passe rien de particulier sur la machine, 
observer que mes disques SSD sont tout à coup devenus plus lents que ma 
connexion

ADSL.

Je serais tenté de tester les disques avec l'outil de diagnostic 
constructeur, spécifique aux SSD, si il existe (je suis resté sur les 
magnétiques pour le stockage de masse (je veux dire autre que l'OS)).


Je serais fort surpris que le problème soit lié aux disques:

* un reboot résout le problème pour plusieurs heures;

* ces disques fonctionnaient parfaitement juste avant le passage en 
Debian 9, et incorrectement juste après;


Tu as essayé avec d'autres versions du noyau ?


--
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Performance RAID instable

[Pascal Hambourg]

Le 23/09/2017 à 15:51, Pierre L. a écrit :


Le 23/09/2017 à 10:40, Pascal Hambourg a écrit :

Le 23/09/2017 à 08:50, Pierre L. a écrit :

Ca me rappelle il y a plusieurs années quand j'avais trouvé une petite
carte PCI pour faire du RAID (sata+IDE) à 2 balles, qui c'était révélée
être du "fakeraid"...

A quoi d'autre t'attendais-tu ?

Tu n'as jamais été jeune ?!


Je le suis encore, mais il y a longtemps que j'ai arrêté de croire au 
père Noël.



Ca sentait le "pilote" intégré à Debian,

C'est-à-dire ?

Pure réflexion de quelqu'un qui n'est (je cite ma précédente réponse)
"absolument pas expert en la matière ;)"


Cela n'explique toujours pas ce que tu entends par "pilote intégré à 
Debian".



Les échanges sont faits pour s'enrichir en connaissance !


A condition de se comprendre.


J'ai souvenir que pour installer Debian sur du raid, il fallait
absolument ajouter dmraid=true dans la ligne de commande du cd
d'install, ce qui signifie qu'il s'agit de fakeraid et que c'est donc
géré par l'OS ?


Uniquement pour le fakeRAID. Pas nécessaire pour utiliser le RAID
logiciel natif de Linux (md).


Donc si j'ai bien compris le principe, si on configure notre chipset de
carte mère (un truc de bureau hein) pour faire du fakeraid (ok ?)


Oui.

Re: Performance RAID instable

[Pierre L.]

Le 23/09/2017 à 10:40, Pascal Hambourg a écrit :
> Le 23/09/2017 à 08:50, Pierre L. a écrit :
>> Ca me rappelle il y a plusieurs années quand j'avais trouvé une petite
>> carte PCI pour faire du RAID (sata+IDE) à 2 balles, qui c'était révélée
>> être du "fakeraid"...
> A quoi d'autre t'attendais-tu ?
Tu n'as jamais été jeune ?!

>> Possibilité d'installer et d'utiliser le Raid0 qui
>> était dessus, mais il finissait par perdre les perfs jusqu'à
>> l'octet/s :s
>> Souvent la machine freezait de longs moments !
>> Par contre c'était cool avec Windows.
> C'est-à-dire ?
Linux = performances pourries
Windows = OK

>> Ca sentait le "pilote" intégré à Debian,
> C'est-à-dire ?
Pure réflexion de quelqu'un qui n'est (je cite ma précédente réponse)
"absolument pas expert en la matière ;) "
Les échanges sont faits pour s'enrichir en connaissance !

>> J'ai souvenir que pour installer Debian sur du raid, il fallait
>> absolument ajouter dmraid=true dans la ligne de commande du cd
>> d'install, ce qui signifie qu'il s'agit de fakeraid et que c'est donc
>> géré par l'OS ?
>
> Uniquement pour le fakeRAID. Pas nécessaire pour utiliser le RAID
> logiciel natif de Linux (md).
>
Donc si j'ai bien compris le principe, si on configure notre chipset de
carte mère (un truc de bureau hein) pour faire du fakeraid (ok ?)

Merci pour les réponses agréables et les élagages de citations inutiles.
C'est toujours sympa d'être au contact des humains courtois et...
"humains" !
Bien à vous



signature.asc
Description: OpenPGP digital signature

Re: Performance RAID instable

[Jean-Michel OLTRA]

Bonjour,


Le samedi 23 septembre 2017, Pascal Hambourg a écrit...


> PS : les uns et les autres, ce serait sympa pour les lecteurs d'élaguer les
> citations inutiles des messages auxquels vous répondez.

+1

-- 
jm

Re: Performance RAID instable

[Pascal Hambourg]

Le 23/09/2017 à 11:57, Seb a écrit :


Après j'avoue que ca m'a toujours un peu perdu ces histoires de 
fakeraid...


J'aurais dû préciser quelque chose qui n'était qu'implicite dans mon 
message initial: tout mes tableaux RAID sont en soft, gérés par 'mdadm'. 


C'était clairement indiqué dans le contenu de /proc/mdstat.

PS : les uns et les autres, ce serait sympa pour les lecteurs d'élaguer 
les citations inutiles des messages auxquels vous répondez.

Re: Performance RAID instable

[Seb]

Hello,


Après j'avoue que ca m'a toujours un peu perdu ces histoires de 
fakeraid...


J'aurais dû préciser quelque chose qui n'était qu'implicite dans mon 
message initial: tout mes tableaux RAID sont en soft, gérés par 'mdadm'. 
Je n'utilise aucune carte RAID.


J'ai souvenir que pour installer Debian sur du raid, il fallait 
absolument ajouter dmraid=true dans la ligne de commande du cd 
d'install, ce qui signifie qu'il s'agit de fakeraid et que c'est donc 
géré par l'OS ?


Je configure le RAID soft avec le partitionneur de Debian (version 
manuelle), lors de l'installation.



Seb.






Le 22/09/2017 à 17:09, Seb a écrit :


Bonjour,



Les astuces que j'ai décrites permettent de maintenir les
performances quand on écrit une grande quantité de données d'un coup
ou bien une grandes quantité d'écritures aléatoirement réparties.
C'est donné au cas où l'hypothèse que j'ai émise est la bonne, car ça
colle très bien à ce que j'observe sur les supports amovibles. Reste
à vérifier si l'architecture dont j'ai parlé est la même sur les SSD.
J'irai jeter un oeil par curiosité.


La comparaison me paraît limitée: sur mon système, je peux copier des
centaines de Mo sans aucun problème à pleine vitesse puis, une heure
plus tard, alors qu'il ne se passe rien de particulier sur la machine,
observer que mes disques SSD sont tout à coup devenus plus lents que
ma connexion
ADSL.


Je serais tenté de tester les disques avec l'outil de diagnostic
constructeur, spécifique aux SSD, si il existe (je suis resté sur les
magnétiques pour le stockage de masse (je veux dire autre que l'OS)).


Je serais fort surpris que le problème soit lié aux disques:

* un reboot résout le problème pour plusieurs heures;

* ces disques fonctionnaient parfaitement juste avant le passage en
Debian 9, et incorrectement juste après;

* j'observe la chose sur deux machines, dont une neuve.


D'ailleurs avec LVM ou RAID + hotswap ça peut se faire à chaud sans
période d'arrêt ou très courte.


Sous réserve d'avoir des disques SSD d'avance, ce qui n'est pas mon
cas...


Seb.




Le vendredi 22 septembre 2017 à 16:12 +0200, Seb a écrit :

Hello,



Les SSD prennent ils en charge TRIM ?


Oui.

~>sudo smartctl -i /dev/sda | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

~>sudo smartctl -i /dev/sdb | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

http://www.samsung.com/fr/consumer/memory-storage/ssd/850-evo/MZ-75E1
T0B/EU/
(^F TRIM)

(Je m'étais assuré de ce point quand j'avais acheté les disques.)

Je rappelle en outre que le même tableau RAID1 avec les mêmes disques
SSD
a fonctionné pendant longtemps sans aucun souci -- jusqu'au passage
de
cette machine de Debian 8 à Debian 9.


L'effondrement de performance ne serait-il consécutif à une

écriture en

peu de temps de quelques centaines de Mo, ou bien de nombreuses
écritures très petites (< 32Ko environ) ?


Il m'arrive couramment de déplacer ou copier des centaines de Mo en
peu de
temps, mais ces moments ne coïncident pas avec la perte de
performance.
Des crontabs font des tas de jobs pour moi en sous-main, mais elles
les
faisaient aussi sous Debian 8.


Je n'utilise pas JFS, mais a t il été optimisé si possible pour
respecter les contraintes techniques de ce genre de support ?


J'ai utilisé JFS sur des tas de machines depuis 10-15 ans, des
disques
seuls, des tableaux RAID1, 5 et 6, je n'ai jamais eu de problème
comparable à celui que je constate aujourd'hui. J'ai signalé JFS pour
le
cas où quelqu'un aurait connaissance d'un changement dans la prise
en
charge de ce filesystem dans Debian, mais autrement, en lui-même, il
m'a
toujours semblé très solide.


Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout

cas

sur une clé USB bas de gamme ça fait des miracles.


Merci pour ces astuces d'optimisation. Mon problème est toutefois
inverse:
empêcher la chute soudaine et inexpliquée des performances, plutôt
que
tirer autant de débit que possible d'un système fonctionnant
correctement
à la base :-)


Seb.



J'utilise Debian depuis une quinzaine d'années, sans problème de
RAID
jusqu'à présent. Mon souci actuel est que deux machines qui font
chacune
du RAID1 sur deux disques SSD ont des performances disque qui se
dégradent
brutalement, sans raison apparente (rien trouvé dans syslog,
notamment).
La vitesse du tableau passe, en gros, de 600 Mo/s à 0,5 Mo/s. La
différence est si nette qu'une mesure grossière avec 'dd' suffit à
la
mettre en évidence (dd if=/dev/zero of=dd.big bs=1k count=1).

* La machine à la maison en a été la première victime, dès son
installation sous Debian 8 en janvier 2017 (Debian 8 téléchargée

en

janvier aussi). Le PC était neuf, ses disques aussi. (C'est

toujours

la
version stable de Debian que j'utilise.)

* La machine de bureau, qui donnait entière satisfaction depuis
plusieurs
années, a commencé à montrer les mêmes symptômes juste après son
passage de
Debian 8 à Debian 9 en juillet 2017. Avant 

Re: Performance RAID instable

[Pascal Hambourg]

Le 23/09/2017 à 08:50, Pierre L. a écrit :

Ca me rappelle il y a plusieurs années quand j'avais trouvé une petite
carte PCI pour faire du RAID (sata+IDE) à 2 balles, qui c'était révélée
être du "fakeraid"...


A quoi d'autre t'attendais-tu ?
Seules les grosses cartes RAID chères font du vrai RAID matériel.
Donc on oublie le fakeRAID et on utilise le RAID logiciel natif de 
Linux, bien plus stable et fiable que n'importe quel fakeRAID dépendant 
du matériel dont le seul avantage est la compatibilité avec Windows.



Possibilité d'installer et d'utiliser le Raid0 qui
était dessus, mais il finissait par perdre les perfs jusqu'à l'octet/s :s
Souvent la machine freezait de longs moments !
Par contre c'était cool avec Windows.


C'est-à-dire ?


Ca sentait le "pilote" intégré à Debian,


C'est-à-dire ?


selon mon avis par déduction absolument pas expert en la matière ;)
Peut-être suis-je complètement à coté de la plaque !!!


Etant donné que je ne vois absolument pas ce que tu veux dire, je suis 
bien incapable d'émettre un avis sur la question.



J'ai souvenir que pour installer Debian sur du raid, il fallait
absolument ajouter dmraid=true dans la ligne de commande du cd
d'install, ce qui signifie qu'il s'agit de fakeraid et que c'est donc
géré par l'OS ?


Uniquement pour le fakeRAID. Pas nécessaire pour utiliser le RAID 
logiciel natif de Linux (md).

Re: Performance RAID instable

[Pierre L.]

Hello,
Ca me rappelle il y a plusieurs années quand j'avais trouvé une petite
carte PCI pour faire du RAID (sata+IDE) à 2 balles, qui c'était révélée
être du "fakeraid"... Possibilité d'installer et d'utiliser le Raid0 qui
était dessus, mais il finissait par perdre les perfs jusqu'à l'octet/s :s
Souvent la machine freezait de longs moments !
Par contre c'était cool avec Windows. Ca sentait le "pilote" intégré à
Debian, selon mon avis par déduction absolument pas expert en la matière ;)
Peut-être suis-je complètement à coté de la plaque !!!

Après j'avoue que ca m'a toujours un peu perdu ces histoires de fakeraid...
J'ai souvenir que pour installer Debian sur du raid, il fallait
absolument ajouter dmraid=true dans la ligne de commande du cd
d'install, ce qui signifie qu'il s'agit de fakeraid et que c'est donc
géré par l'OS ?



Le 22/09/2017 à 17:09, Seb a écrit :
>
> Bonjour,
>
>
>> Les astuces que j'ai décrites permettent de maintenir les
>> performances quand on écrit une grande quantité de données d'un coup
>> ou bien une grandes quantité d'écritures aléatoirement réparties.
>> C'est donné au cas où l'hypothèse que j'ai émise est la bonne, car ça
>> colle très bien à ce que j'observe sur les supports amovibles. Reste
>> à vérifier si l'architecture dont j'ai parlé est la même sur les SSD.
>> J'irai jeter un oeil par curiosité.
>
> La comparaison me paraît limitée: sur mon système, je peux copier des
> centaines de Mo sans aucun problème à pleine vitesse puis, une heure
> plus tard, alors qu'il ne se passe rien de particulier sur la machine,
> observer que mes disques SSD sont tout à coup devenus plus lents que
> ma connexion
> ADSL.
>
>> Je serais tenté de tester les disques avec l'outil de diagnostic
>> constructeur, spécifique aux SSD, si il existe (je suis resté sur les
>> magnétiques pour le stockage de masse (je veux dire autre que l'OS)).
>
> Je serais fort surpris que le problème soit lié aux disques:
>
> * un reboot résout le problème pour plusieurs heures;
>
> * ces disques fonctionnaient parfaitement juste avant le passage en
> Debian 9, et incorrectement juste après;
>
> * j'observe la chose sur deux machines, dont une neuve.
>
>> D'ailleurs avec LVM ou RAID + hotswap ça peut se faire à chaud sans
>> période d'arrêt ou très courte.
>
> Sous réserve d'avoir des disques SSD d'avance, ce qui n'est pas mon
> cas...
>
>
> Seb.
>
>
>>
>> Le vendredi 22 septembre 2017 à 16:12 +0200, Seb a écrit :
>>> Hello,
>>>
>>>
>>>> Les SSD prennent ils en charge TRIM ?
>>>
>>> Oui.
>>>
>>> ~>sudo smartctl -i /dev/sda | grep ^"Device Model"
>>> Device Model: Samsung SSD 850 EVO 1TB
>>>
>>> ~>sudo smartctl -i /dev/sdb | grep ^"Device Model"
>>> Device Model: Samsung SSD 850 EVO 1TB
>>>
>>> http://www.samsung.com/fr/consumer/memory-storage/ssd/850-evo/MZ-75E1
>>> T0B/EU/
>>> (^F TRIM)
>>>
>>> (Je m'étais assuré de ce point quand j'avais acheté les disques.)
>>>
>>> Je rappelle en outre que le même tableau RAID1 avec les mêmes disques
>>> SSD
>>> a fonctionné pendant longtemps sans aucun souci -- jusqu'au passage
>>> de
>>> cette machine de Debian 8 à Debian 9.
>>>
>>>> L'effondrement de performance ne serait-il consécutif à une
>>> écriture en
>>>> peu de temps de quelques centaines de Mo, ou bien de nombreuses
>>>> écritures très petites (< 32Ko environ) ?
>>>
>>> Il m'arrive couramment de déplacer ou copier des centaines de Mo en
>>> peu de
>>> temps, mais ces moments ne coïncident pas avec la perte de
>>> performance.
>>> Des crontabs font des tas de jobs pour moi en sous-main, mais elles
>>> les
>>> faisaient aussi sous Debian 8.
>>>
>>>> Je n'utilise pas JFS, mais a t il été optimisé si possible pour
>>>> respecter les contraintes techniques de ce genre de support ?
>>>
>>> J'ai utilisé JFS sur des tas de machines depuis 10-15 ans, des
>>> disques
>>> seuls, des tableaux RAID1, 5 et 6, je n'ai jamais eu de problème
>>> comparable à celui que je constate aujourd'hui. J'ai signalé JFS pour
>>> le
>>> cas où quelqu'un aurait connaissance d'un changement dans la prise
>>> en
>>> charge de ce filesystem dans Debian, mais autrement, en lui-même, il
>>> m'a
>>> toujours semblé très solide.
>>>
>>>> Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout
>>> cas
>>>> sur

Re: Performance RAID instable

[Seb]

Bonjour,


Les astuces que j'ai décrites permettent de maintenir les performances 
quand on écrit une grande quantité de données d'un coup ou bien une 
grandes quantité d'écritures aléatoirement réparties. C'est donné au cas 
où l'hypothèse que j'ai émise est la bonne, car ça colle très bien à ce 
que j'observe sur les supports amovibles. Reste à vérifier si 
l'architecture dont j'ai parlé est la même sur les SSD. J'irai jeter un 
oeil par curiosité.


La comparaison me paraît limitée: sur mon système, je peux copier des 
centaines de Mo sans aucun problème à pleine vitesse puis, une heure plus 
tard, alors qu'il ne se passe rien de particulier sur la machine, observer 
que mes disques SSD sont tout à coup devenus plus lents que ma connexion

ADSL.

Je serais tenté de tester les disques avec l'outil de diagnostic 
constructeur, spécifique aux SSD, si il existe (je suis resté sur les 
magnétiques pour le stockage de masse (je veux dire autre que l'OS)).


Je serais fort surpris que le problème soit lié aux disques:

* un reboot résout le problème pour plusieurs heures;

* ces disques fonctionnaient parfaitement juste avant le passage en 
Debian 9, et incorrectement juste après;


* j'observe la chose sur deux machines, dont une neuve.

D'ailleurs avec LVM ou RAID + hotswap ça peut se faire à chaud sans 
période d'arrêt ou très courte.


Sous réserve d'avoir des disques SSD d'avance, ce qui n'est pas mon cas...


Seb.




Le vendredi 22 septembre 2017 à 16:12 +0200, Seb a écrit :

Hello,



Les SSD prennent ils en charge TRIM ?


Oui.

~>sudo smartctl -i /dev/sda | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

~>sudo smartctl -i /dev/sdb | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

http://www.samsung.com/fr/consumer/memory-storage/ssd/850-evo/MZ-75E1
T0B/EU/
(^F TRIM)

(Je m'étais assuré de ce point quand j'avais acheté les disques.)

Je rappelle en outre que le même tableau RAID1 avec les mêmes disques
SSD
a fonctionné pendant longtemps sans aucun souci -- jusqu'au passage
de
cette machine de Debian 8 à Debian 9.


L'effondrement de performance ne serait-il consécutif à une

écriture en

peu de temps de quelques centaines de Mo, ou bien de nombreuses
écritures très petites (< 32Ko environ) ?


Il m'arrive couramment de déplacer ou copier des centaines de Mo en
peu de
temps, mais ces moments ne coïncident pas avec la perte de
performance.
Des crontabs font des tas de jobs pour moi en sous-main, mais elles
les
faisaient aussi sous Debian 8.


Je n'utilise pas JFS, mais a t il été optimisé si possible pour
respecter les contraintes techniques de ce genre de support ?


J'ai utilisé JFS sur des tas de machines depuis 10-15 ans, des
disques
seuls, des tableaux RAID1, 5 et 6, je n'ai jamais eu de problème
comparable à celui que je constate aujourd'hui. J'ai signalé JFS pour
le
cas où quelqu'un aurait connaissance d'un changement dans la prise
en
charge de ce filesystem dans Debian, mais autrement, en lui-même, il
m'a
toujours semblé très solide.


Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout

cas

sur une clé USB bas de gamme ça fait des miracles.


Merci pour ces astuces d'optimisation. Mon problème est toutefois
inverse:
empêcher la chute soudaine et inexpliquée des performances, plutôt
que
tirer autant de débit que possible d'un système fonctionnant
correctement
à la base :-)


Seb.



J'utilise Debian depuis une quinzaine d'années, sans problème de
RAID
jusqu'à présent. Mon souci actuel est que deux machines qui font
chacune
du RAID1 sur deux disques SSD ont des performances disque qui se
dégradent
brutalement, sans raison apparente (rien trouvé dans syslog,
notamment).
La vitesse du tableau passe, en gros, de 600 Mo/s à 0,5 Mo/s. La
différence est si nette qu'une mesure grossière avec 'dd' suffit à
la
mettre en évidence (dd if=/dev/zero of=dd.big bs=1k count=1).

* La machine à la maison en a été la première victime, dès son
installation sous Debian 8 en janvier 2017 (Debian 8 téléchargée

en

janvier aussi). Le PC était neuf, ses disques aussi. (C'est

toujours

la
version stable de Debian que j'utilise.)

* La machine de bureau, qui donnait entière satisfaction depuis
plusieurs
années, a commencé à montrer les mêmes symptômes juste après son
passage de
Debian 8 à Debian 9 en juillet 2017. Avant la réinstallation (ce
n'était pas
une migration de 8 à 9 ne nécessitant qu'un reboot), la Debian 8
n'était que
partiellement à jour car j'utilise apt-get upgrade mais jamais

dist-

upgrade. La
version de Debian 8 sur la machine à la maison en janvier 2017

était

donc en un
sens plus récente que la version de Debian 8 sur la machine de

bureau

en
juillet 2017.

* Par ailleurs, j'ai passé deux autres machines en Debian 9 sans
rencontrer le
problème, mais elles font toutes deux du RAID6 sur des disques à
plateaux.

* Les quatre machines utilisent exclusivement JFS.

Je souligne que même quand les performances deviennent a

Re : Re : Performance RAID instable

[Thierry Bugier]

Je ne reproche rien à JFS, sinon d'être populaire :)

Vu le modèle, c'est clair ils ont TRIM, plus aucun disque ne doit être
produit sans cette techno. 

Les astuces que j'ai décrites permettent de maintenir les performances
quand on écrit une grande quantité de données d'un coup ou bien une
grandes quantité d'écritures aléatoirement réparties. C'est donné au
cas où l'hypothèse que j'ai émise est la bonne, car ça colle très bien
à ce que j'observe sur les supports amovibles. Reste à vérifier si
l'architecture dont j'ai parlé est la même sur les SSD. J'irai jeter un
oeil par curiosité.

Je serais tenté de tester les disques avec l'outil de diagnostic
constructeur, spécifique aux SSD, si il existe (je suis resté sur les
magnétiques pour le stockage de masse (je veux dire autre que l'OS)). A
faire seulement si vous avez des disques fiables sur lesquels migrer la
grappe.

D'ailleurs avec LVM ou RAID + hotswap ça peut se faire à chaud sans
période d'arrêt ou très courte. 

Le vendredi 22 septembre 2017 à 16:12 +0200, Seb a écrit :
> Hello,
> 
> 
> > Les SSD prennent ils en charge TRIM ?
> 
> Oui.
> 
> ~>sudo smartctl -i /dev/sda | grep ^"Device Model"
> Device Model: Samsung SSD 850 EVO 1TB
> 
> ~>sudo smartctl -i /dev/sdb | grep ^"Device Model"
> Device Model: Samsung SSD 850 EVO 1TB
> 
> http://www.samsung.com/fr/consumer/memory-storage/ssd/850-evo/MZ-75E1
> T0B/EU/
> (^F TRIM)
> 
> (Je m'étais assuré de ce point quand j'avais acheté les disques.)
> 
> Je rappelle en outre que le même tableau RAID1 avec les mêmes disques
> SSD 
> a fonctionné pendant longtemps sans aucun souci -- jusqu'au passage
> de 
> cette machine de Debian 8 à Debian 9.
> 
> > L'effondrement de performance ne serait-il consécutif à une
> écriture en 
> > peu de temps de quelques centaines de Mo, ou bien de nombreuses 
> > écritures très petites (< 32Ko environ) ?
> 
> Il m'arrive couramment de déplacer ou copier des centaines de Mo en
> peu de 
> temps, mais ces moments ne coïncident pas avec la perte de
> performance. 
> Des crontabs font des tas de jobs pour moi en sous-main, mais elles
> les 
> faisaient aussi sous Debian 8.
> 
> > Je n'utilise pas JFS, mais a t il été optimisé si possible pour 
> > respecter les contraintes techniques de ce genre de support ?
> 
> J'ai utilisé JFS sur des tas de machines depuis 10-15 ans, des
> disques 
> seuls, des tableaux RAID1, 5 et 6, je n'ai jamais eu de problème 
> comparable à celui que je constate aujourd'hui. J'ai signalé JFS pour
> le 
> cas où quelqu'un aurait connaissance d'un changement dans la prise
> en 
> charge de ce filesystem dans Debian, mais autrement, en lui-même, il
> m'a 
> toujours semblé très solide.
> 
> > Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout
> cas 
> > sur une clé USB bas de gamme ça fait des miracles.
> 
> Merci pour ces astuces d'optimisation. Mon problème est toutefois
> inverse: 
> empêcher la chute soudaine et inexpliquée des performances, plutôt
> que 
> tirer autant de débit que possible d'un système fonctionnant
> correctement 
> à la base :-)
> 
> 
> Seb.
> 
> 
> >> J'utilise Debian depuis une quinzaine d'années, sans problème de
> >> RAID
> >> jusqu'à présent. Mon souci actuel est que deux machines qui font
> >> chacune
> >> du RAID1 sur deux disques SSD ont des performances disque qui se
> >> dégradent
> >> brutalement, sans raison apparente (rien trouvé dans syslog,
> >> notamment).
> >> La vitesse du tableau passe, en gros, de 600 Mo/s à 0,5 Mo/s. La
> >> différence est si nette qu'une mesure grossière avec 'dd' suffit à
> >> la
> >> mettre en évidence (dd if=/dev/zero of=dd.big bs=1k count=1).
> >>
> >> * La machine à la maison en a été la première victime, dès son
> >> installation sous Debian 8 en janvier 2017 (Debian 8 téléchargée
> en
> >> janvier aussi). Le PC était neuf, ses disques aussi. (C'est
> toujours
> >> la
> >> version stable de Debian que j'utilise.)
> >>
> >> * La machine de bureau, qui donnait entière satisfaction depuis
> >> plusieurs
> >> années, a commencé à montrer les mêmes symptômes juste après son
> >> passage de
> >> Debian 8 à Debian 9 en juillet 2017. Avant la réinstallation (ce
> >> n'était pas
> >> une migration de 8 à 9 ne nécessitant qu'un reboot), la Debian 8
> >> n'était que
> >> partiellement à jour car j'utilise apt-get upgrade mais jamais
> dist-
> >> upgrade. La
> >> version de Debian 8 sur la machine à la maison en janvier 2017
> était
> >&

Re: Re : Performance RAID instable

[Seb]

Hello,



Les SSD prennent ils en charge TRIM ?


Oui.

~>sudo smartctl -i /dev/sda | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

~>sudo smartctl -i /dev/sdb | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

http://www.samsung.com/fr/consumer/memory-storage/ssd/850-evo/MZ-75E1T0B/EU/
(^F TRIM)

(Je m'étais assuré de ce point quand j'avais acheté les disques.)

Je rappelle en outre que le même tableau RAID1 avec les mêmes disques SSD 
a fonctionné pendant longtemps sans aucun souci -- jusqu'au passage de 
cette machine de Debian 8 à Debian 9.


L'effondrement de performance ne serait-il consécutif à une écriture en 
peu de temps de quelques centaines de Mo, ou bien de nombreuses 
écritures très petites (< 32Ko environ) ?


Il m'arrive couramment de déplacer ou copier des centaines de Mo en peu de 
temps, mais ces moments ne coïncident pas avec la perte de performance. 
Des crontabs font des tas de jobs pour moi en sous-main, mais elles les 
faisaient aussi sous Debian 8.


Je n'utilise pas JFS, mais a t il été optimisé si possible pour 
respecter les contraintes techniques de ce genre de support ?


J'ai utilisé JFS sur des tas de machines depuis 10-15 ans, des disques 
seuls, des tableaux RAID1, 5 et 6, je n'ai jamais eu de problème 
comparable à celui que je constate aujourd'hui. J'ai signalé JFS pour le 
cas où quelqu'un aurait connaissance d'un changement dans la prise en 
charge de ce filesystem dans Debian, mais autrement, en lui-même, il m'a 
toujours semblé très solide.


Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout cas 
sur une clé USB bas de gamme ça fait des miracles.


Merci pour ces astuces d'optimisation. Mon problème est toutefois inverse: 
empêcher la chute soudaine et inexpliquée des performances, plutôt que 
tirer autant de débit que possible d'un système fonctionnant correctement 
à la base :-)



Seb.



J'utilise Debian depuis une quinzaine d'années, sans problème de
RAID
jusqu'à présent. Mon souci actuel est que deux machines qui font
chacune
du RAID1 sur deux disques SSD ont des performances disque qui se
dégradent
brutalement, sans raison apparente (rien trouvé dans syslog,
notamment).
La vitesse du tableau passe, en gros, de 600 Mo/s à 0,5 Mo/s. La
différence est si nette qu'une mesure grossière avec 'dd' suffit à
la
mettre en évidence (dd if=/dev/zero of=dd.big bs=1k count=1).

* La machine à la maison en a été la première victime, dès son
installation sous Debian 8 en janvier 2017 (Debian 8 téléchargée en
janvier aussi). Le PC était neuf, ses disques aussi. (C'est toujours
la
version stable de Debian que j'utilise.)

* La machine de bureau, qui donnait entière satisfaction depuis
plusieurs
années, a commencé à montrer les mêmes symptômes juste après son
passage de
Debian 8 à Debian 9 en juillet 2017. Avant la réinstallation (ce
n'était pas
une migration de 8 à 9 ne nécessitant qu'un reboot), la Debian 8
n'était que
partiellement à jour car j'utilise apt-get upgrade mais jamais dist-
upgrade. La
version de Debian 8 sur la machine à la maison en janvier 2017 était
donc en un
sens plus récente que la version de Debian 8 sur la machine de bureau
en
juillet 2017.

* Par ailleurs, j'ai passé deux autres machines en Debian 9 sans
rencontrer le
problème, mais elles font toutes deux du RAID6 sur des disques à
plateaux.

* Les quatre machines utilisent exclusivement JFS.

Je souligne que même quand les performances deviennent abyssales, les
tableaux
RAID fonctionnent. On peut par exemple copier un fichier ('cp').

Redémarrer la machine restaure la performance normale. La performance
reste
alors stable pendant plusieurs heures. Puis elle s'écroule, ce qui
peut
arriver même quand il n'y a personne devant l'écran, en pleine nuit.

Je joins ci-dessous le résultat des commandes suivantes, lancées sur
la machine
de bureau (RAID1 sur sda+sdb):
smartctl -t short /dev/sda
smartctl -l selftest /dev/sda
smartctl -t short /dev/sdb
smartctl -l selftest /dev/sdb

Est-ce que ces comportements vous évoquent des souvenirs, ou des
pistes à
creuser ? Comment pourrais-je extraire du système des informations
sur
l'origine du problème ? Voyez-vous quels changements intervenus dans
la
Debian 8, après la release initiale, pourraient causer ce
comportement ?


Merci d'avance pour votre aide !
Seb.

PS: si quelqu'un sait comment régler le p'tit problème suivant, ça me
sera
utile aussi: jusqu'à la Debian 8 incluse, quand je faisais un copier-
coller
d'une ligne entière depuis un xterm vers un xterm exécutant zsh, la
commande
s'exécutait dès l'étape coller. Depuis le passage à Debian 9, la
commande
collée apparaît en inverse vidéo, un retour à la ligne a bien été
inséré (le
curseur est sur une nouvelle ligne), mais cela ne provoque pas
l'exécution de
la commande, il faut encore que j'appuie sur Entrée. J'aimerais bien
revenir à
la situation précédente (pas besoin d'appuyer sur Entrée) mais

Re : Performance RAID instable

[Thierry Bugier]

Bonjour

Quelques questions:

Les SSD prennent ils en charge TRIM ?

L'effondrement de performance ne serait-il consécutif à une écriture en
peu de temps de quelques centaines de Mo, ou bien de nombreuses
écritures très petites (< 32Ko environ) ?

Je n'utilise pas JFS, mais a t il été optimisé si possible pour
respecter les contraintes techniques de ce genre de support ?

Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout cas
sur une clé USB bas de gamme ça fait des miracles.

Les stockages "solide" ou "flash" connaissent la notion de bloc
d'effacement. C'est à dire que quand on écrit une donnée on va modifier
sur un de ces blocs, si la donnée écrite diffère d'un seul bit du
contenu préalablement enregistré, il faut effacer tout le bloc et le
réécrire entièrement. Une exception, si les tous bits devant être
modifiés passent de l'état 0 à l'état 1 et pas l'inverse.

Donc pour un seul bit, on peut se retrouver à écrire en réalité un bloc
 de l'ordre du Mo. Du gâchis en somme. 

J'ai eu à utiliser une clé USB ces dernières semaines pour transférer
quelques Go d'un PC à un autre. En optimisant le système de fichiers
ext4 (la clé étatn une bouse de supermarché) j'ai ou atteindre un débit
entre 15 et 20 Mo/s. Au delà de mes espérances pour le support que
j'avais.

L'astuce consiste à configurer le système de fichier pour écrire par
blocs de taille multiple du bloc d'effacement.

Pour trouver la  taille de ce bloc d'effacement, trouvez dans les
dépôts Debian le paquet flashbench. Le site donne des infos sur
l'interprétation des résultats: https://github.com/bradfa/flashbench

En cherchant une source pour expliquer l'optimisation d'un support
flash (usb ou SD) je retrouve sur la source qui m'a tout appris. Je la
redonne donc ici : https://blogofterje.wordpress.com/2012/01/14/optimiz
ing-fs-on-sd-card/

Elle explique aussi l'alignement des partitions, et le "segment size"
dont j'ai oublié de parler.

Dans le cas d'un RAID, il faudra faire des configurations similaires au
niveau de la grappe. C'est paramétrable et à l'époque des disques
magnétiques on optimisait déjà les performances en configurant finement
ses grappes. Un vieil exemple : http://monblog.system-linux.net/blog/20
11/07/02/modification-de-lalignement-disque-lors-de-linstallation-dune-
mandriva-2009-0/

Encore une fois, il faut vérifier si ça s'applique aux SSD, je pense
que oui, mais sans avoir de preuve pour l'instant. Je n'ai pas eu de
problème particulier en me contentant d'aligner mes partitions (il
supporte TRIM).



Le vendredi 22 septembre 2017 à 12:22 +0200, Seb a écrit :
> Bonjour !
> 
> 
> J'utilise Debian depuis une quinzaine d'années, sans problème de
> RAID 
> jusqu'à présent. Mon souci actuel est que deux machines qui font
> chacune 
> du RAID1 sur deux disques SSD ont des performances disque qui se
> dégradent 
> brutalement, sans raison apparente (rien trouvé dans syslog,
> notamment). 
> La vitesse du tableau passe, en gros, de 600 Mo/s à 0,5 Mo/s. La 
> différence est si nette qu'une mesure grossière avec 'dd' suffit à
> la 
> mettre en évidence (dd if=/dev/zero of=dd.big bs=1k count=1).
> 
> * La machine à la maison en a été la première victime, dès son 
> installation sous Debian 8 en janvier 2017 (Debian 8 téléchargée en 
> janvier aussi). Le PC était neuf, ses disques aussi. (C'est toujours
> la 
> version stable de Debian que j'utilise.)
> 
> * La machine de bureau, qui donnait entière satisfaction depuis
> plusieurs 
> années, a commencé à montrer les mêmes symptômes juste après son
> passage de 
> Debian 8 à Debian 9 en juillet 2017. Avant la réinstallation (ce
> n'était pas 
> une migration de 8 à 9 ne nécessitant qu'un reboot), la Debian 8
> n'était que 
> partiellement à jour car j'utilise apt-get upgrade mais jamais dist-
> upgrade. La 
> version de Debian 8 sur la machine à la maison en janvier 2017 était
> donc en un 
> sens plus récente que la version de Debian 8 sur la machine de bureau
> en 
> juillet 2017.
> 
> * Par ailleurs, j'ai passé deux autres machines en Debian 9 sans
> rencontrer le 
> problème, mais elles font toutes deux du RAID6 sur des disques à
> plateaux.
> 
> * Les quatre machines utilisent exclusivement JFS.
> 
> Je souligne que même quand les performances deviennent abyssales, les
> tableaux 
> RAID fonctionnent. On peut par exemple copier un fichier ('cp').
> 
> Redémarrer la machine restaure la performance normale. La performance
> reste 
> alors stable pendant plusieurs heures. Puis elle s'écroule, ce qui
> peut 
> arriver même quand il n'y a personne devant l'écran, en pleine nuit.
> 
> Je joins ci-dessous le résultat des commandes suivantes, lancées sur
> la machine 
> de bureau (RAID1 sur sda+sdb):
> smartctl -t short /dev/sda
> smartctl -l selftes

Performance RAID instable

[Seb]

Bonjour !


J'utilise Debian depuis une quinzaine d'années, sans problème de RAID 
jusqu'à présent. Mon souci actuel est que deux machines qui font chacune 
du RAID1 sur deux disques SSD ont des performances disque qui se dégradent 
brutalement, sans raison apparente (rien trouvé dans syslog, notamment). 
La vitesse du tableau passe, en gros, de 600 Mo/s à 0,5 Mo/s. La 
différence est si nette qu'une mesure grossière avec 'dd' suffit à la 
mettre en évidence (dd if=/dev/zero of=dd.big bs=1k count=1).


* La machine à la maison en a été la première victime, dès son 
installation sous Debian 8 en janvier 2017 (Debian 8 téléchargée en 
janvier aussi). Le PC était neuf, ses disques aussi. (C'est toujours la 
version stable de Debian que j'utilise.)


* La machine de bureau, qui donnait entière satisfaction depuis plusieurs 
années, a commencé à montrer les mêmes symptômes juste après son passage de 
Debian 8 à Debian 9 en juillet 2017. Avant la réinstallation (ce n'était pas 
une migration de 8 à 9 ne nécessitant qu'un reboot), la Debian 8 n'était que 
partiellement à jour car j'utilise apt-get upgrade mais jamais dist-upgrade. La 
version de Debian 8 sur la machine à la maison en janvier 2017 était donc en un 
sens plus récente que la version de Debian 8 sur la machine de bureau en 
juillet 2017.


* Par ailleurs, j'ai passé deux autres machines en Debian 9 sans rencontrer le 
problème, mais elles font toutes deux du RAID6 sur des disques à plateaux.


* Les quatre machines utilisent exclusivement JFS.

Je souligne que même quand les performances deviennent abyssales, les tableaux 
RAID fonctionnent. On peut par exemple copier un fichier ('cp').


Redémarrer la machine restaure la performance normale. La performance reste 
alors stable pendant plusieurs heures. Puis elle s'écroule, ce qui peut 
arriver même quand il n'y a personne devant l'écran, en pleine nuit.


Je joins ci-dessous le résultat des commandes suivantes, lancées sur la machine 
de bureau (RAID1 sur sda+sdb):

smartctl -t short /dev/sda
smartctl -l selftest /dev/sda
smartctl -t short /dev/sdb
smartctl -l selftest /dev/sdb

Est-ce que ces comportements vous évoquent des souvenirs, ou des pistes à 
creuser ? Comment pourrais-je extraire du système des informations sur 
l'origine du problème ? Voyez-vous quels changements intervenus dans la 
Debian 8, après la release initiale, pourraient causer ce comportement ?



Merci d'avance pour votre aide !
Seb.

PS: si quelqu'un sait comment régler le p'tit problème suivant, ça me sera 
utile aussi: jusqu'à la Debian 8 incluse, quand je faisais un copier-coller 
d'une ligne entière depuis un xterm vers un xterm exécutant zsh, la commande 
s'exécutait dès l'étape coller. Depuis le passage à Debian 9, la commande 
collée apparaît en inverse vidéo, un retour à la ligne a bien été inséré (le 
curseur est sur une nouvelle ligne), mais cela ne provoque pas l'exécution de 
la commande, il faut encore que j'appuie sur Entrée. J'aimerais bien revenir à 
la situation précédente (pas besoin d'appuyer sur Entrée) mais je ne sais pas 
ce qu'il faut régler...


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

#smartctl -l selftest /dev/sda
smartctl 6.6 2016-05-31 r4324 [i686-linux-4.9.0-3-686-pae] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_DescriptionStatus  Remaining LifeTime(hours) 
LBA_of_first_error

# 1  Short offline   Completed without error   00% 17786  -
# 2  Short offline   Completed without error   00% 15666  -

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

#smartctl -l selftest /dev/sdb
smartctl 6.6 2016-05-31 r4324 [i686-linux-4.9.0-3-686-pae] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_DescriptionStatus  Remaining LifeTime(hours) 
LBA_of_first_error

# 1  Short offline   Completed without error   00% 16593  -

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] 
[raid10]

md3 : active raid1 sdb3[1] sda3[0]
  951464640 blocks super 1.2 [2/2] [UU]
  bitmap: 2/8 pages [8KB], 65536KB chunk

md2 : active raid1 sda1[0] sdb1[1]
  20955136 blocks super 1.2 [2/2] [UU]

unused devices: 

mdadm grow RAID 5 4->5 DD bloqué depuis +ieurs jours

[Yann Cohen]

Bonjour,

J'ai décidé d'ajouter 1DD dans un raid 5. Donc :
mdadm /dev/md2 --add /dev/sdg1
et puis
mdadm --grow --raid-devices=5 /dev/md2

la dernière m'a donné un retour avec un "blockage de backup" :
mdadm: Need to backup xxxK of critical section

Depuis la seule chose qui varie dans le système c'est le temps avant la
fin de l'opération qui augmente mais le pourcentage d'accomplissement
lui reste à 0%...

/dev/md2 est un pv d'un vg qui héberge les partitions de VM Xen, au
moment des commandes aucune VM étaient actives et le VG lui était actif.

Depuis les VM sont démarrées...

Bon comment me sortir de cela sans tout casser...

mettre 'max' dans sync_max ?

merci.

Yann.





root@xianco:/sys/block/md2/md# cat sync_action 
reshape
root@xianco:/sys/block/md2/md# cat sync_completed 
0 / 1953518592
root@xianco:/sys/block/md2/md# cat resync_start 
none
root@xianco:/sys/block/md2/md# cat sync_max 
0



mdadm --detail /dev/md2
/dev/md2:
Version : 1.2
  Creation Time : Mon Dec 20 12:09:25 2010
 Raid Level : raid5
 Array Size : 2930277888 (2794.53 GiB 3000.60 GB)
  Used Dev Size : 976759296 (931.51 GiB 1000.20 GB)
   Raid Devices : 5
  Total Devices : 5
Persistence : Superblock is persistent

Update Time : Fri Jun  3 07:21:50 2016
  State : active, reshaping 
 Active Devices : 5
Working Devices : 5
 Failed Devices : 0
  Spare Devices : 0

 Layout : left-symmetric
 Chunk Size : 512K

 Reshape Status : 0% complete
  Delta Devices : 1, (4->5)

   Name : xianco:2  (local to host xianco)
   UUID : 45781d95:9f37ba57:6ae4e955:2977f9fb
 Events : 849886

Number   Major   Minor   RaidDevice State
   0   8   330  active sync   /dev/sdc1
   1   8   651  active sync   /dev/sde1
   2   8   492  active sync   /dev/sdd1
   4   8   813  active sync   /dev/sdf1
   5   8   974  active sync   /dev/sdg1

Re: Restauration d'une config LVM / mdadm raid 1

[Damien TOURDE]

Bonjour,

On 03/02/2016 00:05, Pascal Hambourg wrote:
> /dev/md0: TYPE="promise_fasttrack_raid_member"
> A mon avis, je le répète, c'est de ce côté qu'il faut chercher.
>
>
>
Je pense que tu as raison Pascal, je n'avais pas saisi la signification
de "promise".

Il y a fort longtemps, du temps où j'ignorais la "débilité", et le
risque, du raid pseudo-hardware (ce sont des disques de 150Go tout de
même, il y a plus récent), ces disques étaient utilisés avec un fakeraid
d'une CM MSI.

Depuis, je l'ai ai utilisés sur un petit serveur en RAID mdadm, sans
gros soucis, et à nouveau en RAID mdadm aujourd'hui en attendant de
renouveler les disques pour plus gros.
J'ai arrêté de les mettre sur le serveur car, d'une part, le serveur
n'est plus, et d'autre part, il "grattent" fort donc boucan du diable.

Soit je les ai mal formatés et ils contiennent encore des superblocks de
l'ancien raid géré par le chipset de la vieille CM, soit j'ai fait une
boulette dans la config de ma CM actuelle, je vais creuser là dessus.


Mais je ne trouve pas de cas similaires ou approchant sur Google, il va
falloir faire ça "à l'ancienne", si j'y arrive...


En revanche, je n'avais pas rencontré de soucis sur mon ancien serveur
au niveau du boot... et là, c'est pas logique...