J'ai un (vieux) PC sous Gentoo que je trouve subitement (vraiment du
jour au lendemain) très très lent.
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.
J'ai d'abord pensé que ça pouvait être un pb réseau (il est en filaire)
mais les tests que j'ai pu faire (simple wget gros fichier) n'ont rien
rélévé d'anormal.
Ce n'est pas de la charge proc (un Quad core), un top ne donne rien du
tout.
Il ne s'est rien passé au niveau logiciel Í ce moment entre temps, pas
la moindre mise Í jour.
J'en déduis que ça pourrait être un problème de lenteur disque.
Ce PC contient le premier SSD que j'ai eu, et je n'ai aucune expérience
de SSD défaillant.
Le résultat d'un hdparm -tT /dev/sdb me laisse sceptique par rapport Í
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
Un smartctl -l ne m'indique rien de particulier Í mes yeux.
Voici le smartctl -a
=== START OF INFORMATION SECTION ===
Model Family: SandForce Driven SSDs
Device Model: KINGSTON SV300S37A120G
Serial Number: 50026B776B030418
LU WWN Device Id: 5 0026b7 76b030418
Firmware Version: 60AABBF0
User Capacity: 120Â 034Â 123Â 776 bytes [120 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
TRIM Command: Available
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS, ACS-2 T13/2015-D revision 3
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 1.5 Gb/s)
Local Time is: Sun Dec 5 18:56:31 2021 AST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x03) Offline data collection activity
is in progress.
Auto Offline Data Collection:
Disabled. Self-test execution status: ( 243) Self-test routine in
progress... 30% of test remaining.
Total time to complete Offline
data collection: ( 612) seconds.
Offline data collection
capabilities: (0x7d) SMART execute Offline immediate.
No Auto Offline data collection
support. Abort Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging
supported. Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 48) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x0025) SCT Status supported.
SCT Data Table supported.
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining
LifeTime(hours) LBA_of_first_error # 1 Short offline Completed
without error 00% 2908 - # 2 Short offline
Completed without error 00% 2903 - # 3 Short
offline Completed without error 00% 2887 - # 4
Short offline Completed without error 00% 2876
- # 5 Short offline Completed without error 00% 2870
- # 6 Short offline Completed without error 00%
2861 - # 7 Short offline Completed without error
00% 2851 - # 8 Short offline Completed without
error 00% 2843 - # 9 Short offline Completed
without error 00% 2836 - #10 Short offline
Completed without error 00% 2824 - #11 Short
offline Completed without error 00% 2818 - #12
Short offline Completed without error 00% 2807
- #13 Short offline Completed without error 00% 2797
- #14 Short offline Completed without error 00%
2788 - #15 Short offline Completed without error
00% 2777 - #16 Short offline Completed without
error 00% 2774 - #17 Short offline Completed
without error 00% 2772 - #18 Short offline
Completed without error 00% 2770 - #19 Short
offline Completed without error 00% 2768 - #20
Short offline Interrupted (host reset) 40% 2767
- #21 Short offline Completed without error 00% 2765
-
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute
delay.
Est-ce un disque qui l͢che ?
Je ne vois rien qui le dise, mais je ne vois que ça qui puisse être en
cause.
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.
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). 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, mais j'en ai très peu en vraie production.
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.
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).
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, mais j'en ai très peu en vraie production.
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.
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). 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, mais j'en ai très peu en vraie production.
pehache
Le 06/12/2021 Í 00:12, Christophe PEREZ a écrit :
Bonjour, J'ai un (vieux) PC sous Gentoo que je trouve subitement (vraiment du jour au lendemain) très très lent. 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. J'ai d'abord pensé que ça pouvait être un pb réseau (il est en filaire) mais les tests que j'ai pu faire (simple wget gros fichier) n'ont rien rélévé d'anormal. Ce n'est pas de la charge proc (un Quad core), un top ne donne rien du tout. Il ne s'est rien passé au niveau logiciel Í ce moment entre temps, pas la moindre mise Í jour. J'en déduis que ça pourrait être un problème de lenteur disque. Ce PC contient le premier SSD que j'ai eu, et je n'ai aucune expérience de SSD défaillant. Le résultat d'un hdparm -tT /dev/sdb me laisse sceptique par rapport Í 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
Pas clair : c'est un hdparm que tu fais tourner sur le SSD qui te pose problème, o͹ sur un autre ?
Un smartctl -l ne m'indique rien de particulier Í mes yeux.
La mise en page est illisible...
Le 06/12/2021 Í 00:12, Christophe PEREZ a écrit :
Bonjour,
J'ai un (vieux) PC sous Gentoo que je trouve subitement (vraiment du
jour au lendemain) très très lent.
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.
J'ai d'abord pensé que ça pouvait être un pb réseau (il est en filaire)
mais les tests que j'ai pu faire (simple wget gros fichier) n'ont rien
rélévé d'anormal.
Ce n'est pas de la charge proc (un Quad core), un top ne donne rien du
tout.
Il ne s'est rien passé au niveau logiciel Í ce moment entre temps, pas
la moindre mise Í jour.
J'en déduis que ça pourrait être un problème de lenteur disque.
Ce PC contient le premier SSD que j'ai eu, et je n'ai aucune expérience
de SSD défaillant.
Le résultat d'un hdparm -tT /dev/sdb me laisse sceptique par rapport Í
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
Pas clair : c'est un hdparm que tu fais tourner sur le SSD qui te pose
problème, o͹ sur un autre ?
Un smartctl -l ne m'indique rien de particulier Í mes yeux.
Bonjour, J'ai un (vieux) PC sous Gentoo que je trouve subitement (vraiment du jour au lendemain) très très lent. 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. J'ai d'abord pensé que ça pouvait être un pb réseau (il est en filaire) mais les tests que j'ai pu faire (simple wget gros fichier) n'ont rien rélévé d'anormal. Ce n'est pas de la charge proc (un Quad core), un top ne donne rien du tout. Il ne s'est rien passé au niveau logiciel Í ce moment entre temps, pas la moindre mise Í jour. J'en déduis que ça pourrait être un problème de lenteur disque. Ce PC contient le premier SSD que j'ai eu, et je n'ai aucune expérience de SSD défaillant. Le résultat d'un hdparm -tT /dev/sdb me laisse sceptique par rapport Í 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
Pas clair : c'est un hdparm que tu fais tourner sur le SSD qui te pose problème, o͹ sur un autre ?
Un smartctl -l ne m'indique rien de particulier Í mes yeux.
La mise en page est illisible...
Marc SCHAEFER
Christophe PEREZ wrote:
6 Go/10 min == 10 MByte/s.
Et ? Ça, c'est en temps normal.
C'est déjÍ assez lent, en fait. Cela peut être lié au temps de compression ou de collecte de tas de petits fichiers.
Mais je n'arrive pas Í être convaincu que le problème soit le disque, c'est pour ça que j'ai fourni ces infos. Elles semblent "normales" ou pas ?
Oui, avec débit indiqué par hdparm on s'attendra Í un backup en 2 minutes. Maintenant, l'écriture est peut-être bien plus lente que la lecture testée par hdparm.
Même une connexion ssh prend du temps Í s'effectuer.
Ceci fait penser Í un problème de DNS.
C'est juste *comme si* le PC/proc avait un mode ultra-économique qui le ralentissait.
des processus étranges qui tournent (top, htop) et prennent du CPU ou de la mémoire? Le système swappe-t-il activement (colonnes si et so de `vmstat 5`, laisser tourner quelques minutes, la 1ère ligne est une moyenne).
Et puis, un processeur ne peut pas devenir plus lent non ? Il sera défectueux, provoquera des erreurs, mais il ne peut pas tourner 100 fois moins vite il me semble.
C'est effectivement peu probable.
Christophe PEREZ <chris@novazur.fr> wrote:
6 Go/10 min == 10 MByte/s.
Et ?
Ça, c'est en temps normal.
C'est déjÍ assez lent, en fait. Cela peut être lié au temps de
compression ou de collecte de tas de petits fichiers.
Mais je n'arrive pas Í être convaincu que le problème soit le disque,
c'est pour ça que j'ai fourni ces infos.
Elles semblent "normales" ou pas ?
Oui, avec débit indiqué par hdparm on s'attendra Í un backup en 2
minutes.
Maintenant, l'écriture est peut-être bien plus lente que la lecture
testée par hdparm.
Même une connexion ssh prend du temps Í s'effectuer.
Ceci fait penser Í un problème de DNS.
C'est juste *comme si* le PC/proc avait un mode ultra-économique qui le
ralentissait.
des processus étranges qui tournent (top, htop) et prennent du CPU ou de
la mémoire?
Le système swappe-t-il activement (colonnes si et so de `vmstat 5`,
laisser tourner quelques minutes, la 1ère ligne est une moyenne).
Et puis, un processeur ne peut pas devenir plus lent non ? Il sera
défectueux, provoquera des erreurs, mais il ne peut pas tourner 100
fois moins vite il me semble.
C'est déjÍ assez lent, en fait. Cela peut être lié au temps de compression ou de collecte de tas de petits fichiers.
Mais je n'arrive pas Í être convaincu que le problème soit le disque, c'est pour ça que j'ai fourni ces infos. Elles semblent "normales" ou pas ?
Oui, avec débit indiqué par hdparm on s'attendra Í un backup en 2 minutes. Maintenant, l'écriture est peut-être bien plus lente que la lecture testée par hdparm.
Même une connexion ssh prend du temps Í s'effectuer.
Ceci fait penser Í un problème de DNS.
C'est juste *comme si* le PC/proc avait un mode ultra-économique qui le ralentissait.
des processus étranges qui tournent (top, htop) et prennent du CPU ou de la mémoire? Le système swappe-t-il activement (colonnes si et so de `vmstat 5`, laisser tourner quelques minutes, la 1ère ligne est une moyenne).
Et puis, un processeur ne peut pas devenir plus lent non ? Il sera défectueux, provoquera des erreurs, mais il ne peut pas tourner 100 fois moins vite il me semble.
C'est effectivement peu probable.
Marc SCHAEFER
Christophe PEREZ wrote:
6 Go/10 min == 10 MByte/s.
Et ? Ça, c'est en temps normal.
C'est déjÍ assez lent, en fait. Cela peut être lié au temps de compression ou de collecte de tas de petits fichiers.
Mais je n'arrive pas Í être convaincu que le problème soit le disque, c'est pour ça que j'ai fourni ces infos. Elles semblent "normales" ou pas ?
Oui, avec débit indiqué par hdparm on s'attendra Í un backup en 2 minutes. Maintenant, l'écriture est peut-être bien plus lente que la lecture testée par hdparm.
Même une connexion ssh prend du temps Í s'effectuer.
Ceci fait penser Í un problème de DNS.
C'est juste *comme si* le PC/proc avait un mode ultra-économique qui le ralentissait.
des processus étranges qui tournent (top, htop) et prennent du CPU ou de la mémoire? Le système swappe-t-il activement (colonnes si et so de `vmstat 5`, laisser tourner quelques minutes, la 1ère ligne est une moyenne).
Et puis, un processeur ne peut pas devenir plus lent non ? Il sera défectueux, provoquera des erreurs, mais il ne peut pas tourner 100 fois moins vite il me semble.
C'est effectivement peu probable. Des erreurs dans `sudo dmesg | tail' ?
Christophe PEREZ <chris@novazur.fr> wrote:
6 Go/10 min == 10 MByte/s.
Et ?
Ça, c'est en temps normal.
C'est déjÍ assez lent, en fait. Cela peut être lié au temps de
compression ou de collecte de tas de petits fichiers.
Mais je n'arrive pas Í être convaincu que le problème soit le disque,
c'est pour ça que j'ai fourni ces infos.
Elles semblent "normales" ou pas ?
Oui, avec débit indiqué par hdparm on s'attendra Í un backup en 2
minutes.
Maintenant, l'écriture est peut-être bien plus lente que la lecture
testée par hdparm.
Même une connexion ssh prend du temps Í s'effectuer.
Ceci fait penser Í un problème de DNS.
C'est juste *comme si* le PC/proc avait un mode ultra-économique qui le
ralentissait.
des processus étranges qui tournent (top, htop) et prennent du CPU ou de
la mémoire?
Le système swappe-t-il activement (colonnes si et so de `vmstat 5`,
laisser tourner quelques minutes, la 1ère ligne est une moyenne).
Et puis, un processeur ne peut pas devenir plus lent non ? Il sera
défectueux, provoquera des erreurs, mais il ne peut pas tourner 100
fois moins vite il me semble.
C'est déjÍ assez lent, en fait. Cela peut être lié au temps de compression ou de collecte de tas de petits fichiers.
Mais je n'arrive pas Í être convaincu que le problème soit le disque, c'est pour ça que j'ai fourni ces infos. Elles semblent "normales" ou pas ?
Oui, avec débit indiqué par hdparm on s'attendra Í un backup en 2 minutes. Maintenant, l'écriture est peut-être bien plus lente que la lecture testée par hdparm.
Même une connexion ssh prend du temps Í s'effectuer.
Ceci fait penser Í un problème de DNS.
C'est juste *comme si* le PC/proc avait un mode ultra-économique qui le ralentissait.
des processus étranges qui tournent (top, htop) et prennent du CPU ou de la mémoire? Le système swappe-t-il activement (colonnes si et so de `vmstat 5`, laisser tourner quelques minutes, la 1ère ligne est une moyenne).
Et puis, un processeur ne peut pas devenir plus lent non ? Il sera défectueux, provoquera des erreurs, mais il ne peut pas tourner 100 fois moins vite il me semble.
C'est effectivement peu probable. Des erreurs dans `sudo dmesg | tail' ?
pehache
Le 06/12/2021 Í 08:20, Marc SCHAEFER a écrit :
Christophe PEREZ 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.
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.
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.
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.
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.
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.
Marc SCHAEFER
pehache wrote:
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.
Effectivement, le SSD n'a aucun moyen de savoir qu'ils ne sont pas alloués. Par contre, il a moyen de voir qu'ils n'ont jamais été utilisés. Typiquement, le fait que la commande `trim' existe me faisait penser qu'il pouvait avoir -- en plus d'un pré-effacement -- utilisation des blocs non alloués comme blocs de réallocation. Je me disais qu'il pouvait éventuellement noter quels blocs logiques sont mappés o͹, et mapper au fur et Í mesure. Mais c'est plus complexe qu'une simple table de réallocation avec des blocs réservés pour. Je cite Wikipedia: "Cette technique permet en outre d'augmenter la durée de vie des SSD, par la mise en rotation des cellules utilisées Í chaque écriture - Í la condition de laisser suffisamment d'espace libre sur le support. En effet, plus l'espace de stockage disponible est restreint, plus les écritures se feront fréquemment sur les mêmes cellules, réduisant donc l'efficacité de cette technique. "
pehache <pehache.7@gmail.com> wrote:
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.
Effectivement, le SSD n'a aucun moyen de savoir qu'ils ne sont pas
alloués. Par contre, il a moyen de voir qu'ils n'ont jamais été
utilisés.
Typiquement, le fait que la commande `trim' existe me faisait penser
qu'il pouvait avoir -- en plus d'un pré-effacement -- utilisation des
blocs non alloués comme blocs de réallocation.
Je me disais qu'il pouvait éventuellement noter quels blocs logiques
sont mappés o͹, et mapper au fur et Í mesure. Mais c'est plus complexe
qu'une simple table de réallocation avec des blocs réservés pour.
Je cite Wikipedia: "Cette technique permet en outre d'augmenter la durée
de vie des SSD, par la mise en rotation des cellules utilisées Í chaque
écriture - Í la condition de laisser suffisamment d'espace libre sur le
support. En effet, plus l'espace de stockage disponible est restreint,
plus les écritures se feront fréquemment sur les mêmes cellules,
réduisant donc l'efficacité de cette technique. "
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.
Effectivement, le SSD n'a aucun moyen de savoir qu'ils ne sont pas alloués. Par contre, il a moyen de voir qu'ils n'ont jamais été utilisés. Typiquement, le fait que la commande `trim' existe me faisait penser qu'il pouvait avoir -- en plus d'un pré-effacement -- utilisation des blocs non alloués comme blocs de réallocation. Je me disais qu'il pouvait éventuellement noter quels blocs logiques sont mappés o͹, et mapper au fur et Í mesure. Mais c'est plus complexe qu'une simple table de réallocation avec des blocs réservés pour. Je cite Wikipedia: "Cette technique permet en outre d'augmenter la durée de vie des SSD, par la mise en rotation des cellules utilisées Í chaque écriture - Í la condition de laisser suffisamment d'espace libre sur le support. En effet, plus l'espace de stockage disponible est restreint, plus les écritures se feront fréquemment sur les mêmes cellules, réduisant donc l'efficacité de cette technique. "
pehache
Le 06/12/2021 Í 18:58, Marc SCHAEFER a écrit :
pehache wrote:
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.
Effectivement, le SSD n'a aucun moyen de savoir qu'ils ne sont pas alloués. Par contre, il a moyen de voir qu'ils n'ont jamais été utilisés. Typiquement, le fait que la commande `trim' existe me faisait penser qu'il pouvait avoir -- en plus d'un pré-effacement -- utilisation des blocs non alloués comme blocs de réallocation. Je me disais qu'il pouvait éventuellement noter quels blocs logiques sont mappés o͹, et mapper au fur et Í mesure. Mais c'est plus complexe qu'une simple table de réallocation avec des blocs réservés pour.
Il pourrait faire ça, oui, mais il y aurait un "petit" souci si ensuite tu voulais récupérer l'espace initialement non partionné. D'o͹ le fait que la réserve de blocs vient "en plus" de l'espace visible par l'OS.
Je cite Wikipedia: "Cette technique permet en outre d'augmenter la durée de vie des SSD, par la mise en rotation des cellules utilisées Í chaque écriture - Í la condition de laisser suffisamment d'espace libre sur le support. En effet, plus l'espace de stockage disponible est restreint, plus les écritures se feront fréquemment sur les mêmes cellules, réduisant donc l'efficacité de cette technique. "
Oui, mais ça c'est dans le but de permettre au garbage collector de mieux fonctionner (si tant est qu'il y ait besoin qu'il fonctionne mieux).
Le 06/12/2021 Í 18:58, Marc SCHAEFER a écrit :
pehache <pehache.7@gmail.com> wrote:
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.
Effectivement, le SSD n'a aucun moyen de savoir qu'ils ne sont pas
alloués. Par contre, il a moyen de voir qu'ils n'ont jamais été
utilisés.
Typiquement, le fait que la commande `trim' existe me faisait penser
qu'il pouvait avoir -- en plus d'un pré-effacement -- utilisation des
blocs non alloués comme blocs de réallocation.
Je me disais qu'il pouvait éventuellement noter quels blocs logiques
sont mappés o͹, et mapper au fur et Í mesure. Mais c'est plus complexe
qu'une simple table de réallocation avec des blocs réservés pour.
Il pourrait faire ça, oui, mais il y aurait un "petit" souci si ensuite
tu voulais récupérer l'espace initialement non partionné. D'o͹ le fait
que la réserve de blocs vient "en plus" de l'espace visible par l'OS.
Je cite Wikipedia: "Cette technique permet en outre d'augmenter la durée
de vie des SSD, par la mise en rotation des cellules utilisées Í chaque
écriture - Í la condition de laisser suffisamment d'espace libre sur le
support. En effet, plus l'espace de stockage disponible est restreint,
plus les écritures se feront fréquemment sur les mêmes cellules,
réduisant donc l'efficacité de cette technique. "
Oui, mais ça c'est dans le but de permettre au garbage collector de mieux
fonctionner (si tant est qu'il y ait besoin qu'il fonctionne mieux).
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.
Effectivement, le SSD n'a aucun moyen de savoir qu'ils ne sont pas alloués. Par contre, il a moyen de voir qu'ils n'ont jamais été utilisés. Typiquement, le fait que la commande `trim' existe me faisait penser qu'il pouvait avoir -- en plus d'un pré-effacement -- utilisation des blocs non alloués comme blocs de réallocation. Je me disais qu'il pouvait éventuellement noter quels blocs logiques sont mappés o͹, et mapper au fur et Í mesure. Mais c'est plus complexe qu'une simple table de réallocation avec des blocs réservés pour.
Il pourrait faire ça, oui, mais il y aurait un "petit" souci si ensuite tu voulais récupérer l'espace initialement non partionné. D'o͹ le fait que la réserve de blocs vient "en plus" de l'espace visible par l'OS.
Je cite Wikipedia: "Cette technique permet en outre d'augmenter la durée de vie des SSD, par la mise en rotation des cellules utilisées Í chaque écriture - Í la condition de laisser suffisamment d'espace libre sur le support. En effet, plus l'espace de stockage disponible est restreint, plus les écritures se feront fréquemment sur les mêmes cellules, réduisant donc l'efficacité de cette technique. "
Oui, mais ça c'est dans le but de permettre au garbage collector de mieux fonctionner (si tant est qu'il y ait besoin qu'il fonctionne mieux).
Christophe PEREZ
Le Mon, 6 Dec 2021 17:10:00 -0000 (UTC), Marc SCHAEFER a écrit :
Christophe PEREZ wrote:
6 Go/10 min == 10 MByte/s.
Et ? Ça, c'est en temps normal.
C'est déjÍ assez lent, en fait. Cela peut être lié au temps de compression ou de collecte de tas de petits fichiers.
Oui, voilÍ , c'est lié Í la lecture, et Í tout le processus de backup qui n'est pas juste une copie de fichier, compression etc... Je donnais la valeur juste pour que l'on soit bien conscient que je ne parle pas d'un léger ralentissement mais de quelque chose tout Í fait hors du commun.
Oui, avec débit indiqué par hdparm on s'attendra Í un backup en 2 minutes.
On reste quand même dans le même ordre de grandeur, on ne passe pas de quelques minutes Í 13 heures.
Maintenant, l'écriture est peut-être bien plus lente que la lecture testée par hdparm.
L'écriture ne se faisant pas sur la même machine surtout. Et c'est lÍ qu'intervient le réseau. Je pensais l'avoir sous-entendu, mais je me rends compte que ce n'était pas forcément suffisamment explicite.
Même une connexion ssh prend du temps Í s'effectuer.
Ceci fait penser Í un problème de DNS.
A priori non, j'ai mon serveur DNS, rien n'a changé, le poste est connu Les résultats sont identiques avec l'adresse IP.
des processus étranges qui tournent (top, htop) et prennent du CPU ou de la mémoire?
Non, rien de rien justement.
Le système swappe-t-il activement (colonnes si et so de `vmstat 5`, laisser tourner quelques minutes, la 1ère ligne est une moyenne).
Non, ce n'est pas ça non plus. Tous ces tests sont faits après reboot, sans rien qui tourne hormis les services "normaux" et sddm. Aucun outil ne montre le moindre élément suspect. vmstat 5, si et so = 0.
Des erreurs dans `sudo dmesg | tail' ?
Rien ne me saute aux yeux. Je me demande si en fait tout n'est pas qu'une question de problème de réseau, que j'aurais Í tort écarté trop tÍ´t je ne sais plus pour quelle raison. Vu qu'en plus le /home est en NFS, le réseau y est crucial. une simple connexion ssh peut prendre 3 ou 13sec... (mais 10sec est le cas général) $ time ssh 192.168.5.7 echo real 0m10,577s user 0m0,000s sys 0m0,009s $ time ssh 192.168.5.7 echo real 0m3,756s user 0m0,005s sys 0m0,005s $ time ssh 192.168.5.7 echo real 0m13,965s user 0m0,009s sys 0m0,000s Pourtant, ethtool ne me semble pas montrer de défaut $ ethtool eth0 Settings for eth0: Supported ports: [ MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: on Port: MII PHYAD: 1 Transceiver: internal netlink error: Operation not permitted Link detected: yes Mais quand je teste avec : $ time scp ~/tmp/test poste_sans_probleme:/dev/null test 100% 500MB 112.0MB/s 00:04 real 0m4,648s user 0m0,864s sys 0m0,745s $ time scp ~/tmp/test 192.168.5.7:/dev/null test 100% 500MB 24.9MB/s 00:20 real 0m27,867s user 0m0,952s sys 0m0,341s Défaillance de la carte réseau intégrée ? Je n'ai jamais rencontré ce type de défaut. Pour moi ça a toujours été on/off. Ça fonctionne, ou c'est HS. CÍ¢ble réseau ? Possible, il est long, et pas simple Í remplacer pour un test. J'imagine qu'il n'y a pas d'autre moyen que de le remplacer pour tester. Je déplacerai la machine dès que je pourrai, pour tester sur un autre cÍ¢ble. En fait, je n'ai jamais eu de défaut de ce genre, encore moins lié Í un cÍ¢ble... Je pensais que c'était lÍ aussi assez binaire, soit c'est bon, soit c'est HS, même si je comprends bien que ça puisse être dégradé.
Le Mon, 6 Dec 2021 17:10:00 -0000 (UTC),
Marc SCHAEFER <schaefer@alphanet.ch> a écrit :
Christophe PEREZ <chris@novazur.fr> wrote:
>> 6 Go/10 min == 10 MByte/s.
>
> Et ?
> Ça, c'est en temps normal.
C'est déjÍ assez lent, en fait. Cela peut être lié au temps de
compression ou de collecte de tas de petits fichiers.
Oui, voilÍ , c'est lié Í la lecture, et Í tout le processus de backup
qui n'est pas juste une copie de fichier, compression etc...
Je donnais la valeur juste pour que l'on soit bien conscient que je ne
parle pas d'un léger ralentissement mais de quelque chose tout Í fait
hors du commun.
Oui, avec débit indiqué par hdparm on s'attendra Í un backup en 2
minutes.
On reste quand même dans le même ordre de grandeur, on ne passe pas de
quelques minutes Í 13 heures.
Maintenant, l'écriture est peut-être bien plus lente que la lecture
testée par hdparm.
L'écriture ne se faisant pas sur la même machine surtout. Et c'est lÍ
qu'intervient le réseau. Je pensais l'avoir sous-entendu, mais je me
rends compte que ce n'était pas forcément suffisamment explicite.
> Même une connexion ssh prend du temps Í s'effectuer.
Ceci fait penser Í un problème de DNS.
A priori non, j'ai mon serveur DNS, rien n'a changé, le poste est connu
Les résultats sont identiques avec l'adresse IP.
des processus étranges qui tournent (top, htop) et prennent du CPU ou
de la mémoire?
Non, rien de rien justement.
Le système swappe-t-il activement (colonnes si et so de `vmstat 5`,
laisser tourner quelques minutes, la 1ère ligne est une moyenne).
Non, ce n'est pas ça non plus. Tous ces tests sont faits après reboot,
sans rien qui tourne hormis les services "normaux" et sddm.
Aucun outil ne montre le moindre élément suspect.
vmstat 5, si et so = 0.
Des erreurs dans `sudo dmesg | tail' ?
Rien ne me saute aux yeux.
Je me demande si en fait tout n'est pas qu'une question de problème de
réseau, que j'aurais Í tort écarté trop tÍ´t je ne sais plus pour quelle
raison. Vu qu'en plus le /home est en NFS, le réseau y est crucial.
une simple connexion ssh peut prendre 3 ou 13sec... (mais 10sec est le
cas général)
$ time ssh 192.168.5.7 echo
real 0m10,577s
user 0m0,000s
sys 0m0,009s
$ time ssh 192.168.5.7 echo
real 0m3,756s
user 0m0,005s
sys 0m0,005s
$ time ssh 192.168.5.7 echo
real 0m13,965s
user 0m0,009s
sys 0m0,000s
Pourtant, ethtool ne me semble pas montrer de défaut
$ ethtool eth0
Settings for eth0:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Port: MII
PHYAD: 1
Transceiver: internal
netlink error: Operation not permitted
Link detected: yes
Mais quand je teste avec :
$ time scp ~/tmp/test poste_sans_probleme:/dev/null
test 100%
500MB 112.0MB/s 00:04
real 0m4,648s
user 0m0,864s
sys 0m0,745s
$ time scp ~/tmp/test 192.168.5.7:/dev/null
test 100%
500MB 24.9MB/s 00:20
real 0m27,867s
user 0m0,952s
sys 0m0,341s
Défaillance de la carte réseau intégrée ?
Je n'ai jamais rencontré ce type de défaut. Pour moi ça a toujours été
on/off. Ça fonctionne, ou c'est HS.
CÍ¢ble réseau ? Possible, il est long, et pas simple Í remplacer pour un
test. J'imagine qu'il n'y a pas d'autre moyen que de le remplacer pour
tester.
Je déplacerai la machine dès que je pourrai, pour tester sur un autre
c͢ble.
En fait, je n'ai jamais eu de défaut de ce genre, encore moins lié Í un
cÍ¢ble... Je pensais que c'était lÍ aussi assez binaire, soit c'est bon,
soit c'est HS, même si je comprends bien que ça puisse être dégradé.
Le Mon, 6 Dec 2021 17:10:00 -0000 (UTC), Marc SCHAEFER a écrit :
Christophe PEREZ wrote:
6 Go/10 min == 10 MByte/s.
Et ? Ça, c'est en temps normal.
C'est déjÍ assez lent, en fait. Cela peut être lié au temps de compression ou de collecte de tas de petits fichiers.
Oui, voilÍ , c'est lié Í la lecture, et Í tout le processus de backup qui n'est pas juste une copie de fichier, compression etc... Je donnais la valeur juste pour que l'on soit bien conscient que je ne parle pas d'un léger ralentissement mais de quelque chose tout Í fait hors du commun.
Oui, avec débit indiqué par hdparm on s'attendra Í un backup en 2 minutes.
On reste quand même dans le même ordre de grandeur, on ne passe pas de quelques minutes Í 13 heures.
Maintenant, l'écriture est peut-être bien plus lente que la lecture testée par hdparm.
L'écriture ne se faisant pas sur la même machine surtout. Et c'est lÍ qu'intervient le réseau. Je pensais l'avoir sous-entendu, mais je me rends compte que ce n'était pas forcément suffisamment explicite.
Même une connexion ssh prend du temps Í s'effectuer.
Ceci fait penser Í un problème de DNS.
A priori non, j'ai mon serveur DNS, rien n'a changé, le poste est connu Les résultats sont identiques avec l'adresse IP.
des processus étranges qui tournent (top, htop) et prennent du CPU ou de la mémoire?
Non, rien de rien justement.
Le système swappe-t-il activement (colonnes si et so de `vmstat 5`, laisser tourner quelques minutes, la 1ère ligne est une moyenne).
Non, ce n'est pas ça non plus. Tous ces tests sont faits après reboot, sans rien qui tourne hormis les services "normaux" et sddm. Aucun outil ne montre le moindre élément suspect. vmstat 5, si et so = 0.
Des erreurs dans `sudo dmesg | tail' ?
Rien ne me saute aux yeux. Je me demande si en fait tout n'est pas qu'une question de problème de réseau, que j'aurais Í tort écarté trop tÍ´t je ne sais plus pour quelle raison. Vu qu'en plus le /home est en NFS, le réseau y est crucial. une simple connexion ssh peut prendre 3 ou 13sec... (mais 10sec est le cas général) $ time ssh 192.168.5.7 echo real 0m10,577s user 0m0,000s sys 0m0,009s $ time ssh 192.168.5.7 echo real 0m3,756s user 0m0,005s sys 0m0,005s $ time ssh 192.168.5.7 echo real 0m13,965s user 0m0,009s sys 0m0,000s Pourtant, ethtool ne me semble pas montrer de défaut $ ethtool eth0 Settings for eth0: Supported ports: [ MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: on Port: MII PHYAD: 1 Transceiver: internal netlink error: Operation not permitted Link detected: yes Mais quand je teste avec : $ time scp ~/tmp/test poste_sans_probleme:/dev/null test 100% 500MB 112.0MB/s 00:04 real 0m4,648s user 0m0,864s sys 0m0,745s $ time scp ~/tmp/test 192.168.5.7:/dev/null test 100% 500MB 24.9MB/s 00:20 real 0m27,867s user 0m0,952s sys 0m0,341s Défaillance de la carte réseau intégrée ? Je n'ai jamais rencontré ce type de défaut. Pour moi ça a toujours été on/off. Ça fonctionne, ou c'est HS. CÍ¢ble réseau ? Possible, il est long, et pas simple Í remplacer pour un test. J'imagine qu'il n'y a pas d'autre moyen que de le remplacer pour tester. Je déplacerai la machine dès que je pourrai, pour tester sur un autre cÍ¢ble. En fait, je n'ai jamais eu de défaut de ce genre, encore moins lié Í un cÍ¢ble... Je pensais que c'était lÍ aussi assez binaire, soit c'est bon, soit c'est HS, même si je comprends bien que ça puisse être dégradé.
Marc SCHAEFER
Christophe PEREZ wrote:
C'est déjÍ assez lent, en fait. Cela peut être lié au temps de compression ou de collecte de tas de petits fichiers.
Oui, voilÍ , c'est lié Í la lecture, et Í tout le processus de backup qui n'est pas juste une copie de fichier, compression etc... Je donnais la valeur juste pour que l'on soit bien conscient que je ne parle pas d'un léger ralentissement mais de quelque chose tout Í fait hors du commun.
Je ne suis plus sÍ»r alors ce qu'est le hdparm que tu as montré: disque source ou disque destination?
On reste quand même dans le même ordre de grandeur, on ne passe pas de quelques minutes Í 13 heures.
Effectivement.
L'écriture ne se faisant pas sur la même machine surtout. Et c'est lÍ qu'intervient le réseau. Je pensais l'avoir sous-entendu, mais je me rends compte que ce n'était pas forcément suffisamment explicite.
un petit schéma: machine 1 ---------- réseau --------------- machine 2 | | disque 1 disque 2 (l'ASCII art ne se lit bien que sans coupures de lignes et avec une fonte non proportionnelle).
Je me demande si en fait tout n'est pas qu'une question de problème de réseau, que j'aurais Í tort écarté trop tÍ´t je ne sais plus pour quelle raison. Vu qu'en plus le /home est en NFS, le réseau y est crucial.
Ah oui, cette information manquait.
Défaillance de la carte réseau intégrée ?
Tu peux regarder les compteurs d'erreur (netstat -i). Tu peux aussi éventuellement vérifier que tu as bien le paquet firmware de ta carte réseau. Tu peux changer les cÍ¢bles et le port du switch.
CÍ¢ble réseau ? Possible, il est long, et pas simple Í remplacer pour un test. J'imagine qu'il n'y a pas d'autre moyen que de le remplacer pour tester.
Ce qui arrive parfois est que la négociation boucle: symptÍ´me, plein de up/down dans dmesg (que tu n'as pas observé). Le débit négocié est correct. Conclusion: oui, c'est le réseau, probablement le cÍ¢ble.
Christophe PEREZ <chris@novazur.fr> wrote:
C'est déjÍ assez lent, en fait. Cela peut être lié au temps de
compression ou de collecte de tas de petits fichiers.
Oui, voilÍ , c'est lié Í la lecture, et Í tout le processus de backup
qui n'est pas juste une copie de fichier, compression etc...
Je donnais la valeur juste pour que l'on soit bien conscient que je ne
parle pas d'un léger ralentissement mais de quelque chose tout Í fait
hors du commun.
Je ne suis plus sÍ»r alors ce qu'est le hdparm que tu as montré: disque
source ou disque destination?
On reste quand même dans le même ordre de grandeur, on ne passe pas de
quelques minutes Í 13 heures.
Effectivement.
L'écriture ne se faisant pas sur la même machine surtout. Et c'est lÍ
qu'intervient le réseau. Je pensais l'avoir sous-entendu, mais je me
rends compte que ce n'était pas forcément suffisamment explicite.
(l'ASCII art ne se lit bien que sans coupures de lignes et avec une
fonte non proportionnelle).
Je me demande si en fait tout n'est pas qu'une question de problème de
réseau, que j'aurais Í tort écarté trop tÍ´t je ne sais plus pour quelle
raison. Vu qu'en plus le /home est en NFS, le réseau y est crucial.
Ah oui, cette information manquait.
Défaillance de la carte réseau intégrée ?
Tu peux regarder les compteurs d'erreur (netstat -i).
Tu peux aussi éventuellement vérifier que tu as bien le paquet firmware
de ta carte réseau.
Tu peux changer les c͢bles et le port du switch.
CÍ¢ble réseau ? Possible, il est long, et pas simple Í remplacer pour un
test. J'imagine qu'il n'y a pas d'autre moyen que de le remplacer pour
tester.
Ce qui arrive parfois est que la négociation boucle: symptÍ´me, plein de
up/down dans dmesg (que tu n'as pas observé).
Le débit négocié est correct.
Conclusion: oui, c'est le réseau, probablement le cÍ¢ble.
C'est déjÍ assez lent, en fait. Cela peut être lié au temps de compression ou de collecte de tas de petits fichiers.
Oui, voilÍ , c'est lié Í la lecture, et Í tout le processus de backup qui n'est pas juste une copie de fichier, compression etc... Je donnais la valeur juste pour que l'on soit bien conscient que je ne parle pas d'un léger ralentissement mais de quelque chose tout Í fait hors du commun.
Je ne suis plus sÍ»r alors ce qu'est le hdparm que tu as montré: disque source ou disque destination?
On reste quand même dans le même ordre de grandeur, on ne passe pas de quelques minutes Í 13 heures.
Effectivement.
L'écriture ne se faisant pas sur la même machine surtout. Et c'est lÍ qu'intervient le réseau. Je pensais l'avoir sous-entendu, mais je me rends compte que ce n'était pas forcément suffisamment explicite.
un petit schéma: machine 1 ---------- réseau --------------- machine 2 | | disque 1 disque 2 (l'ASCII art ne se lit bien que sans coupures de lignes et avec une fonte non proportionnelle).
Je me demande si en fait tout n'est pas qu'une question de problème de réseau, que j'aurais Í tort écarté trop tÍ´t je ne sais plus pour quelle raison. Vu qu'en plus le /home est en NFS, le réseau y est crucial.
Ah oui, cette information manquait.
Défaillance de la carte réseau intégrée ?
Tu peux regarder les compteurs d'erreur (netstat -i). Tu peux aussi éventuellement vérifier que tu as bien le paquet firmware de ta carte réseau. Tu peux changer les cÍ¢bles et le port du switch.
CÍ¢ble réseau ? Possible, il est long, et pas simple Í remplacer pour un test. J'imagine qu'il n'y a pas d'autre moyen que de le remplacer pour tester.
Ce qui arrive parfois est que la négociation boucle: symptÍ´me, plein de up/down dans dmesg (que tu n'as pas observé). Le débit négocié est correct. Conclusion: oui, c'est le réseau, probablement le cÍ¢ble.
Christophe PEREZ
Le Tue, 7 Dec 2021 09:58:51 -0000 (UTC), Marc SCHAEFER a écrit :
Je ne suis plus sÍ»r alors ce qu'est le hdparm que tu as montré: disque source ou disque destination?
Disque source. Le disque destination ne peut pas être en cause, sinon il le serait pour tous les backups de tous les postes, et pas seulement celui-ci (je sais, je suis le seul Í le savoir, mais je ne l'ai pas mis en cause justement parce que je le sais ;) .
un petit schéma: machine 1 ---------- réseau --------------- machine 2 | | disque 1 disque 2
C'est ça.
Ah oui, cette information manquait.
Désolé. Grossière omission, mais ça venait du fait que j'avais écarté la piste du réseau trop tÍ´t. J'avais fait un test sur téléchargement de fichier de mon serveur http, mais sans doute fichier trop petit (18Mo), je n'avais pas plus gros sous la main Í ce moment. Et le temps était le même sur les 2 machines. J'ai déduit trop vite.
Défaillance de la carte réseau intégrée ?
Tu peux regarder les compteurs d'erreur (netstat -i).
$ netstat -i Table d'interfaces noyau Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 747186 0 0 0 97050 0 0 0 BMRU lo 65536 790 0 0 0 790 0 0 0 LRU J'en déduis que ce n'est pas la carte réseau la cause.
Tu peux aussi éventuellement vérifier que tu as bien le paquet firmware de ta carte réseau.
Non, ça non :) Il tourne comme ça depuis 2006. Pas de raison que ça vienne de la. De plus, c'est un module du noyau. Et comme je l'ai dit initialement, rien n'a été modifié logiciellement avant la défaillance.
Tu peux changer les c͢bles et le port du switch.
Le cÍ¢ble c'est compliqué. Il faut que je déplace la machine pour la tester sur un autre cÍ¢ble. C'est prévu. Pour le port du switch, j'y ai pensé, mais je n'étais pas sÍ»r que ça puisse avoir une influence. J'ai éteint et rallumé le switch sans succès, mais pour changer de port, c'est un tout petit peu plus compliqué. Je vais m'y ateler.
Ce qui arrive parfois est que la négociation boucle: symptÍ´me, plein de up/down dans dmesg (que tu n'as pas observé).
Moi je ne vois rien. http://dpaste.com/8EJ6NMCJ6
Le débit négocié est correct. Conclusion: oui, c'est le réseau, probablement le cÍ¢ble.
Sans doute, Í moins que le switch soit en cause, comme évoqué. Merci pour ton aide au diagnostique. Je reviendrai quand j'aurai pu faire les manipulations.
Le Tue, 7 Dec 2021 09:58:51 -0000 (UTC),
Marc SCHAEFER <schaefer@alphanet.ch> a écrit :
Je ne suis plus sÍ»r alors ce qu'est le hdparm que tu as montré: disque
source ou disque destination?
Disque source. Le disque destination ne peut pas être en cause, sinon
il le serait pour tous les backups de tous les postes, et pas seulement
celui-ci (je sais, je suis le seul Í le savoir, mais je ne l'ai pas mis
en cause justement parce que je le sais ;) .
Désolé. Grossière omission, mais ça venait du fait que j'avais écarté
la piste du réseau trop tÍ´t. J'avais fait un test sur téléchargement de
fichier de mon serveur http, mais sans doute fichier trop petit (18Mo),
je n'avais pas plus gros sous la main Í ce moment. Et le temps était le
même sur les 2 machines. J'ai déduit trop vite.
> Défaillance de la carte réseau intégrée ?
Tu peux regarder les compteurs d'erreur (netstat -i).
J'en déduis que ce n'est pas la carte réseau la cause.
Tu peux aussi éventuellement vérifier que tu as bien le paquet
firmware de ta carte réseau.
Non, ça non :) Il tourne comme ça depuis 2006. Pas de raison que ça
vienne de la. De plus, c'est un module du noyau. Et comme je l'ai dit
initialement, rien n'a été modifié logiciellement avant la défaillance.
Tu peux changer les c͢bles et le port du switch.
Le cÍ¢ble c'est compliqué. Il faut que je déplace la machine pour la
tester sur un autre cÍ¢ble. C'est prévu.
Pour le port du switch, j'y ai pensé, mais je n'étais pas sÍ»r que ça
puisse avoir une influence. J'ai éteint et rallumé le switch sans
succès, mais pour changer de port, c'est un tout petit peu plus
compliqué. Je vais m'y ateler.
Ce qui arrive parfois est que la négociation boucle: symptÍ´me, plein
de up/down dans dmesg (que tu n'as pas observé).
Moi je ne vois rien.
http://dpaste.com/8EJ6NMCJ6
Le débit négocié est correct.
Conclusion: oui, c'est le réseau, probablement le cÍ¢ble.
Sans doute, Í moins que le switch soit en cause, comme évoqué.
Merci pour ton aide au diagnostique.
Je reviendrai quand j'aurai pu faire les manipulations.
Le Tue, 7 Dec 2021 09:58:51 -0000 (UTC), Marc SCHAEFER a écrit :
Je ne suis plus sÍ»r alors ce qu'est le hdparm que tu as montré: disque source ou disque destination?
Disque source. Le disque destination ne peut pas être en cause, sinon il le serait pour tous les backups de tous les postes, et pas seulement celui-ci (je sais, je suis le seul Í le savoir, mais je ne l'ai pas mis en cause justement parce que je le sais ;) .
un petit schéma: machine 1 ---------- réseau --------------- machine 2 | | disque 1 disque 2
C'est ça.
Ah oui, cette information manquait.
Désolé. Grossière omission, mais ça venait du fait que j'avais écarté la piste du réseau trop tÍ´t. J'avais fait un test sur téléchargement de fichier de mon serveur http, mais sans doute fichier trop petit (18Mo), je n'avais pas plus gros sous la main Í ce moment. Et le temps était le même sur les 2 machines. J'ai déduit trop vite.
Défaillance de la carte réseau intégrée ?
Tu peux regarder les compteurs d'erreur (netstat -i).
$ netstat -i Table d'interfaces noyau Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 747186 0 0 0 97050 0 0 0 BMRU lo 65536 790 0 0 0 790 0 0 0 LRU J'en déduis que ce n'est pas la carte réseau la cause.
Tu peux aussi éventuellement vérifier que tu as bien le paquet firmware de ta carte réseau.
Non, ça non :) Il tourne comme ça depuis 2006. Pas de raison que ça vienne de la. De plus, c'est un module du noyau. Et comme je l'ai dit initialement, rien n'a été modifié logiciellement avant la défaillance.
Tu peux changer les c͢bles et le port du switch.
Le cÍ¢ble c'est compliqué. Il faut que je déplace la machine pour la tester sur un autre cÍ¢ble. C'est prévu. Pour le port du switch, j'y ai pensé, mais je n'étais pas sÍ»r que ça puisse avoir une influence. J'ai éteint et rallumé le switch sans succès, mais pour changer de port, c'est un tout petit peu plus compliqué. Je vais m'y ateler.
Ce qui arrive parfois est que la négociation boucle: symptÍ´me, plein de up/down dans dmesg (que tu n'as pas observé).
Moi je ne vois rien. http://dpaste.com/8EJ6NMCJ6
Le débit négocié est correct. Conclusion: oui, c'est le réseau, probablement le cÍ¢ble.
Sans doute, Í moins que le switch soit en cause, comme évoqué. Merci pour ton aide au diagnostique. Je reviendrai quand j'aurai pu faire les manipulations.
