Re: lenteur disque (à confirmer)

Le 06/12/2021 à 08:20, Marc SCHAEFER a écrit :

Christophe PEREZ <chris@novazur.fr> wrote:

Pour vous donner une idée de cette lenteur, habituellement, son backup
complet de 6Go par bacula se fait en 10mn environ. Là, il en est à
220Mo en 50mn.

 Il fait son backup sur:
 

mes autres PC avec SSD :
/dev/sdb:
 Timing cached reads:   2694 MB in  2.00 seconds = 1347.05 MB/sec
 Timing buffered disk reads: 390 MB in  3.00 seconds = 129.87 MB/sec

 6 Go/10 min == 10 MByte/s.
 Et il y a encore la compression bacula je suppose qui réduit ce
débit, si le CPU est suffisamment rapide.
 

UPDATED  WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate     0x0032   095
095   050    Old_age   Always       -       0/4950862 5
Retired_Block_Count     0x0033   100   100   003    Pre-fail  Always
   -       0 9 Power_On_Hours_and_Msec 0x0032   093   093   000

 Argh, la mise en page !
 Votre client news a-t-il un mode "brut", sinon le plus simple serait
d'utiliser: https://justpaste.it/ ou autre.
 

Est-ce un disque qui lâche ?

 En général, chez moi, les disques qui tournent voient leur dégradation
en débit (un simple hdparm comme vous avez fait le montre) avant d'avoir
des blocs en erreur.
 Mais le SMART, souvent, ne voit rien (l'indice parfois c'est le
Raw_Read_Error_Rate, dans mon expérience).

J'ai plutôt constaté l'inverse : une lenteur anormale et un rapport SMART qui revèle des problèmes.

 Sur les disques SSD, j'ai trop peu d'expérience. Il faut savoir que par
parano j'ai jusqu'ici systématiquement laissé un bon bout non
partitionné en me disant que cela leur servirait de blocs de
remplacement,

Autant que je sache la réserve de blocs n'est pas sur le volume accessible par l'OS, et même si tu ne partitionnes pas tout, les blocs libres ne seront pas utilisés pour remplacer les blocs défectueux.