Tout est en REISERFS sur disque scsi
Contrôleur scsi SYMBIOS 53c1010-33 Ultra3
Noyau SMP 2.6.8 (2 x 1 MHz) avec option preemptible kernel.
j'ai visiblement un gros souci de performance avec mes partitions reiserfs
3.6.
Le seul autre disque est un NTFS+FAT32; quand je charge un fichier
quelconque de plusieurs Mo ou plus c'est très lent sous REISERFS
(plusieurs secondes pour une image tiff de 18 Mo par exemple).
Par contre quand je le fais avec la partition NTFS c'est quasi instantané!
J'ai essayé avec la FAT32 et idem c'est particulièrement rapide!
(attention j'ai fait un tas de contre manipulations pour éviter les
"erreurs d'appréciation" dues au cache disque)
Je n'ai pas essayé avec une EXT3 car je n'ai pas envie de tout casser!
De toute façon je trouve globalement les accès disque lents (ne serait-ce
que lorsque je charge un simple éditeur de fichier).
Donc quelqu'un sait-il d'où cela peut-il venir: reiserfs et sa
journalisation (je doute pour un simple fichier), la combinaison
SMP/REISERFS/SCSI ou autre chose?
Puis je améliorer ça ou y remédier? Et cela décidera de mon abandon ou pas
de linux car travaillant énormément sur les images je n'ai pas envie de
travailler avec un système au moins 5 fois plus lents dans ce genre de
manipulations!
A noter qu'à l'époque où j'étais sous windows (installé sur ces mêmes
disques) les accès disques étaient particulièrement rapides à tout point
de vue: bref ça "déménageait"!.
Tout est en REISERFS sur disque scsi Contrôleur scsi SYMBIOS 53c1010-33 Ultra3 Noyau SMP 2.6.8 (2 x 1 MHz) avec option preemptible kernel.
j'ai visiblement un gros souci de performance avec mes partitions reiserfs 3.6. Le seul autre disque est un NTFS+FAT32; quand je charge un fichier quelconque de plusieurs Mo ou plus c'est très lent sous REISERFS (plusieurs secondes pour une image tiff de 18 Mo par exemple). Par contre quand je le fais avec la partition NTFS c'est quasi instantané! J'ai essayé avec la FAT32 et idem c'est particulièrement rapide! (attention j'ai fait un tas de contre manipulations pour éviter les "erreurs d'appréciation" dues au cache disque) Je n'ai pas essayé avec une EXT3 car je n'ai pas envie de tout casser! De toute façon je trouve globalement les accès disque lents (ne serait-ce que lorsque je charge un simple éditeur de fichier).
Donc quelqu'un sait-il d'où cela peut-il venir: reiserfs et sa journalisation (je doute pour un simple fichier), la combinaison SMP/REISERFS/SCSI ou autre chose? Puis je améliorer ça ou y remédier? Et cela décidera de mon abandon ou pas de linux car travaillant énormément sur les images je n'ai pas envie de travailler avec un système au moins 5 fois plus lents dans ce genre de manipulations!
A noter qu'à l'époque où j'étais sous windows (installé sur ces mêmes disques) les accès disques étaient particulièrement rapides à tout point de vue: bref ça "déménageait"!.
Merci de vos éclaircissements, Jean-Pierre.
A tout hazard, regarde dans le fichier /var/log/messages pour voir si il n'y aurait pas des problèmes d'écritures sur le disque.
Jean-Pierre wrote:
bonjour à tous,
Tout est en REISERFS sur disque scsi
Contrôleur scsi SYMBIOS 53c1010-33 Ultra3
Noyau SMP 2.6.8 (2 x 1 MHz) avec option preemptible kernel.
j'ai visiblement un gros souci de performance avec mes partitions reiserfs
3.6.
Le seul autre disque est un NTFS+FAT32; quand je charge un fichier
quelconque de plusieurs Mo ou plus c'est très lent sous REISERFS
(plusieurs secondes pour une image tiff de 18 Mo par exemple).
Par contre quand je le fais avec la partition NTFS c'est quasi instantané!
J'ai essayé avec la FAT32 et idem c'est particulièrement rapide!
(attention j'ai fait un tas de contre manipulations pour éviter les
"erreurs d'appréciation" dues au cache disque)
Je n'ai pas essayé avec une EXT3 car je n'ai pas envie de tout casser!
De toute façon je trouve globalement les accès disque lents (ne serait-ce
que lorsque je charge un simple éditeur de fichier).
Donc quelqu'un sait-il d'où cela peut-il venir: reiserfs et sa
journalisation (je doute pour un simple fichier), la combinaison
SMP/REISERFS/SCSI ou autre chose?
Puis je améliorer ça ou y remédier? Et cela décidera de mon abandon ou pas
de linux car travaillant énormément sur les images je n'ai pas envie de
travailler avec un système au moins 5 fois plus lents dans ce genre de
manipulations!
A noter qu'à l'époque où j'étais sous windows (installé sur ces mêmes
disques) les accès disques étaient particulièrement rapides à tout point
de vue: bref ça "déménageait"!.
Merci de vos éclaircissements,
Jean-Pierre.
A tout hazard, regarde dans le fichier /var/log/messages pour voir si il n'y
aurait pas des problèmes d'écritures sur le disque.
Tout est en REISERFS sur disque scsi Contrôleur scsi SYMBIOS 53c1010-33 Ultra3 Noyau SMP 2.6.8 (2 x 1 MHz) avec option preemptible kernel.
j'ai visiblement un gros souci de performance avec mes partitions reiserfs 3.6. Le seul autre disque est un NTFS+FAT32; quand je charge un fichier quelconque de plusieurs Mo ou plus c'est très lent sous REISERFS (plusieurs secondes pour une image tiff de 18 Mo par exemple). Par contre quand je le fais avec la partition NTFS c'est quasi instantané! J'ai essayé avec la FAT32 et idem c'est particulièrement rapide! (attention j'ai fait un tas de contre manipulations pour éviter les "erreurs d'appréciation" dues au cache disque) Je n'ai pas essayé avec une EXT3 car je n'ai pas envie de tout casser! De toute façon je trouve globalement les accès disque lents (ne serait-ce que lorsque je charge un simple éditeur de fichier).
Donc quelqu'un sait-il d'où cela peut-il venir: reiserfs et sa journalisation (je doute pour un simple fichier), la combinaison SMP/REISERFS/SCSI ou autre chose? Puis je améliorer ça ou y remédier? Et cela décidera de mon abandon ou pas de linux car travaillant énormément sur les images je n'ai pas envie de travailler avec un système au moins 5 fois plus lents dans ce genre de manipulations!
A noter qu'à l'époque où j'étais sous windows (installé sur ces mêmes disques) les accès disques étaient particulièrement rapides à tout point de vue: bref ça "déménageait"!.
Merci de vos éclaircissements, Jean-Pierre.
A tout hazard, regarde dans le fichier /var/log/messages pour voir si il n'y aurait pas des problèmes d'écritures sur le disque.
TiChou
Dans le message <news:, *Jean-Pierre* gueula sur f.c.o.l.configuration :
PAS LA PEINE DE GUEULER ! VOUS N'ÊTES PAS LE SEUL ICI À VOULOIR VOUS FAIRE ENTENDRE ET VOUS N'AVEZ DONC PAS LA PRIORITÉ !
bonjour à tous,
Bonjour tout de même.
-- TiChou
Dans le message <news:opsl6np8ojlxt84j@jp>,
*Jean-Pierre* gueula sur f.c.o.l.configuration :
PAS LA PEINE DE GUEULER ! VOUS N'ÊTES PAS LE SEUL ICI À VOULOIR VOUS FAIRE
ENTENDRE ET VOUS N'AVEZ DONC PAS LA PRIORITÉ !
Dans le message <news:, *Jean-Pierre* gueula sur f.c.o.l.configuration :
PAS LA PEINE DE GUEULER ! VOUS N'ÊTES PAS LE SEUL ICI À VOULOIR VOUS FAIRE ENTENDRE ET VOUS N'AVEZ DONC PAS LA PRIORITÉ !
bonjour à tous,
Bonjour tout de même.
-- TiChou
Jean-Pierre
Le Mon, 14 Feb 2005 12:04:54 +0100, Rémi a écrit: A tout hazard, regarde dans le fichier /var/log/messages pour voir si il n'y aurait pas des problèmes d'écritures sur le disque.
non y'a pas la moindre erreur qui traîne!
Le Mon, 14 Feb 2005 12:04:54 +0100, Rémi
<NoPub_remi_inconnu_NoSpam@NoPub_yahoo.fr_NoSpam> a écrit:
A tout hazard, regarde dans le fichier /var/log/messages pour voir si il
n'y
aurait pas des problèmes d'écritures sur le disque.
Le Mon, 14 Feb 2005 12:04:54 +0100, Rémi a écrit: A tout hazard, regarde dans le fichier /var/log/messages pour voir si il n'y aurait pas des problèmes d'écritures sur le disque.
non y'a pas la moindre erreur qui traîne!
Rakotomandimby (R12y) Mihamina
( Mon, 14 Feb 2005 11:35:58 +0100 ) Jean-Pierre :
Puis je améliorer ça ou y remédier?
voir "hdparm" sur lea-linux ? -- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Mon, 14 Feb 2005 11:35:58 +0100 ) Jean-Pierre :
Puis je améliorer ça ou y remédier?
voir "hdparm" sur lea-linux ?
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
voir "hdparm" sur lea-linux ? -- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Tom
bonjour
j'ai aussi un problème de lenteur et je suis aussi avec une partition en Reiserfs. Voir le sujet Disque dur ATA-5
Tom
bonjour
j'ai aussi un problème de lenteur et je suis aussi avec une partition en
Reiserfs. Voir le sujet Disque dur ATA-5
j'ai aussi un problème de lenteur et je suis aussi avec une partition en Reiserfs. Voir le sujet Disque dur ATA-5
Tom
Jean-Pierre
***** voilà ce que ça donne avec hdparm mais pour le scsi ça m'a l'air d'être n'importe quoi car le sdb est un vieux 9 go avec un mini cache matériel et le sda est un 36 go de "course" avec 8 mo de cache!? __________________________________ [ jp]# hdparm -tT /dev/sda1
/dev/sda1: Timing buffer-cache reads: 544 MB in 2.01 seconds = 270.96 MB/sec Timing buffered disk reads: 124 MB in 2.90 seconds = 42.81 MB/sec [ jp]# hdparm -tT /dev/sda5
/dev/sda5: Timing buffer-cache reads: 588 MB in 2.00 seconds = 293.46 MB/sec Timing buffered disk reads: 116 MB in 3.02 seconds = 38.42 MB/sec [ jp]# hdparm -tT /dev/sdb1
/dev/sdb1: Timing buffer-cache reads: 556 MB in 2.00 seconds = 277.90 MB/sec Timing buffered disk reads: 120 MB in 3.01 seconds = 39.86 MB/sec [ jp]#
***** J'ai fait le test avec un disque dur western ata 120 go 8 mo de cache: __________________________________ [ jp]# hdparm -tT /dev/hdd1
/dev/hdd1: Timing buffer-cache reads: 576 MB in 2.01 seconds = 287.04 MB/sec Timing buffered disk reads: 108 MB in 3.02 seconds = 35.71 MB/sec [ jp]#
à bientôt, Jean-Pierre.
*****
voilà ce que ça donne avec hdparm mais pour le scsi ça m'a l'air d'être
n'importe quoi car le sdb est un vieux 9 go avec un mini cache matériel et
le sda est un 36 go de "course" avec 8 mo de cache!?
__________________________________
[root@jp jp]# hdparm -tT /dev/sda1
/dev/sda1:
Timing buffer-cache reads: 544 MB in 2.01 seconds = 270.96 MB/sec
Timing buffered disk reads: 124 MB in 2.90 seconds = 42.81 MB/sec
[root@jp jp]# hdparm -tT /dev/sda5
/dev/sda5:
Timing buffer-cache reads: 588 MB in 2.00 seconds = 293.46 MB/sec
Timing buffered disk reads: 116 MB in 3.02 seconds = 38.42 MB/sec
[root@jp jp]# hdparm -tT /dev/sdb1
/dev/sdb1:
Timing buffer-cache reads: 556 MB in 2.00 seconds = 277.90 MB/sec
Timing buffered disk reads: 120 MB in 3.01 seconds = 39.86 MB/sec
[root@jp jp]#
*****
J'ai fait le test avec un disque dur western ata 120 go 8 mo de cache:
__________________________________
[root@jp jp]# hdparm -tT /dev/hdd1
/dev/hdd1:
Timing buffer-cache reads: 576 MB in 2.01 seconds = 287.04 MB/sec
Timing buffered disk reads: 108 MB in 3.02 seconds = 35.71 MB/sec
[root@jp jp]#
***** voilà ce que ça donne avec hdparm mais pour le scsi ça m'a l'air d'être n'importe quoi car le sdb est un vieux 9 go avec un mini cache matériel et le sda est un 36 go de "course" avec 8 mo de cache!? __________________________________ [ jp]# hdparm -tT /dev/sda1
/dev/sda1: Timing buffer-cache reads: 544 MB in 2.01 seconds = 270.96 MB/sec Timing buffered disk reads: 124 MB in 2.90 seconds = 42.81 MB/sec [ jp]# hdparm -tT /dev/sda5
/dev/sda5: Timing buffer-cache reads: 588 MB in 2.00 seconds = 293.46 MB/sec Timing buffered disk reads: 116 MB in 3.02 seconds = 38.42 MB/sec [ jp]# hdparm -tT /dev/sdb1
/dev/sdb1: Timing buffer-cache reads: 556 MB in 2.00 seconds = 277.90 MB/sec Timing buffered disk reads: 120 MB in 3.01 seconds = 39.86 MB/sec [ jp]#
***** J'ai fait le test avec un disque dur western ata 120 go 8 mo de cache: __________________________________ [ jp]# hdparm -tT /dev/hdd1
/dev/hdd1: Timing buffer-cache reads: 576 MB in 2.01 seconds = 287.04 MB/sec Timing buffered disk reads: 108 MB in 3.02 seconds = 35.71 MB/sec [ jp]#
à bientôt, Jean-Pierre.
Pascal
Salut,
voilà ce que ça donne avec hdparm mais pour le scsi ça m'a l'air d'être n'importe quoi car le sdb est un vieux 9 go avec un mini cache matériel et le sda est un 36 go de "course" avec 8 mo de cache!?
Note : hdparm mesure le débit soutenu en lecture. La taille du cache intégré au disque ne joue pas sur celui-ci.
[ jp]# hdparm -tT /dev/sda1 Timing buffered disk reads: 124 MB in 2.90 seconds = 42.81 MB/sec
Ça me paraît honnête. Qu'appelles-tu un disque "de course" ? En particulier, quelle est sa vitesse de rotation ?
[ jp]# hdparm -tT /dev/sda5 Timing buffered disk reads: 116 MB in 3.02 seconds = 38.42 MB/sec
La mesure est faite plus à l'intérieur des plateaux, donc le débit est logiquement légèrement inférieur.
[ jp]# hdparm -tT /dev/sdb1 Timing buffered disk reads: 120 MB in 3.01 seconds = 39.86 MB/sec
Wow, il n'est pas minable du tout ce vieux 9 Go ! :-D
J'ai fait le test avec un disque dur western ata 120 go 8 mo de cache: [ jp]# hdparm -tT /dev/hdd1 Timing buffered disk reads: 108 MB in 3.02 seconds = 35.71 MB/sec
Ce n'est franchement pas un foudre de guerre compte tenu de sa capacité. Vitesse de rotation de 5400 tours/minute seulement ?
PS : pour être sûr de mesurer le débit maxi en début de disque, il vaut mieux spécifier le nom du disque (sda, hda...) au lieu d'une partition. Avec une partition, le débit dépend de la position de celle-ci comme le montre tes deux premiers tests.
Salut,
voilà ce que ça donne avec hdparm mais pour le scsi ça m'a l'air d'être
n'importe quoi car le sdb est un vieux 9 go avec un mini cache matériel et
le sda est un 36 go de "course" avec 8 mo de cache!?
Note : hdparm mesure le débit soutenu en lecture. La taille du cache
intégré au disque ne joue pas sur celui-ci.
[root@jp jp]# hdparm -tT /dev/sda1
Timing buffered disk reads: 124 MB in 2.90 seconds = 42.81 MB/sec
Ça me paraît honnête. Qu'appelles-tu un disque "de course" ? En
particulier, quelle est sa vitesse de rotation ?
[root@jp jp]# hdparm -tT /dev/sda5
Timing buffered disk reads: 116 MB in 3.02 seconds = 38.42 MB/sec
La mesure est faite plus à l'intérieur des plateaux, donc le débit est
logiquement légèrement inférieur.
[root@jp jp]# hdparm -tT /dev/sdb1
Timing buffered disk reads: 120 MB in 3.01 seconds = 39.86 MB/sec
Wow, il n'est pas minable du tout ce vieux 9 Go ! :-D
J'ai fait le test avec un disque dur western ata 120 go 8 mo de cache:
[root@jp jp]# hdparm -tT /dev/hdd1
Timing buffered disk reads: 108 MB in 3.02 seconds = 35.71 MB/sec
Ce n'est franchement pas un foudre de guerre compte tenu de sa capacité.
Vitesse de rotation de 5400 tours/minute seulement ?
PS : pour être sûr de mesurer le débit maxi en début de disque, il vaut
mieux spécifier le nom du disque (sda, hda...) au lieu d'une partition.
Avec une partition, le débit dépend de la position de celle-ci comme le
montre tes deux premiers tests.
voilà ce que ça donne avec hdparm mais pour le scsi ça m'a l'air d'être n'importe quoi car le sdb est un vieux 9 go avec un mini cache matériel et le sda est un 36 go de "course" avec 8 mo de cache!?
Note : hdparm mesure le débit soutenu en lecture. La taille du cache intégré au disque ne joue pas sur celui-ci.
[ jp]# hdparm -tT /dev/sda1 Timing buffered disk reads: 124 MB in 2.90 seconds = 42.81 MB/sec
Ça me paraît honnête. Qu'appelles-tu un disque "de course" ? En particulier, quelle est sa vitesse de rotation ?
[ jp]# hdparm -tT /dev/sda5 Timing buffered disk reads: 116 MB in 3.02 seconds = 38.42 MB/sec
La mesure est faite plus à l'intérieur des plateaux, donc le débit est logiquement légèrement inférieur.
[ jp]# hdparm -tT /dev/sdb1 Timing buffered disk reads: 120 MB in 3.01 seconds = 39.86 MB/sec
Wow, il n'est pas minable du tout ce vieux 9 Go ! :-D
J'ai fait le test avec un disque dur western ata 120 go 8 mo de cache: [ jp]# hdparm -tT /dev/hdd1 Timing buffered disk reads: 108 MB in 3.02 seconds = 35.71 MB/sec
Ce n'est franchement pas un foudre de guerre compte tenu de sa capacité. Vitesse de rotation de 5400 tours/minute seulement ?
PS : pour être sûr de mesurer le débit maxi en début de disque, il vaut mieux spécifier le nom du disque (sda, hda...) au lieu d'une partition. Avec une partition, le débit dépend de la position de celle-ci comme le montre tes deux premiers tests.
Laurent
TiChou wrote:
Dans le message <news:, *Jean-Pierre* gueula sur f.c.o.l.configuration :
PAS LA PEINE DE GUEULER ! VOUS N'ÊTES PAS LE SEUL ICI À VOULOIR VOUS FAIRE ENTENDRE ET VOUS N'AVEZ DONC PAS LA PRIORITÉ !
bonjour à tous,
Bonjour tout de même.
Peut-être que sa touche Maj se bloque tout simplement.
***** voilà ce que ça donne avec hdparm mais pour le scsi ça m'a l'air d'être n'importe quoi car le sdb est un vieux 9 go avec un mini cache matériel et le sda est un 36 go de "course" avec 8 mo de cache!? __________________________________ [ jp]# hdparm -tT /dev/sda1
/dev/sda1: Timing buffer-cache reads: 544 MB in 2.01 seconds = 270.96 MB/sec Timing buffered disk reads: 124 MB in 2.90 seconds = 42.81 MB/sec [ jp]# hdparm -tT /dev/sda5
/dev/sda5: Timing buffer-cache reads: 588 MB in 2.00 seconds = 293.46 MB/sec Timing buffered disk reads: 116 MB in 3.02 seconds = 38.42 MB/sec [ jp]# hdparm -tT /dev/sdb1
/dev/sdb1: Timing buffer-cache reads: 556 MB in 2.00 seconds = 277.90 MB/sec Timing buffered disk reads: 120 MB in 3.01 seconds = 39.86 MB/sec [ jp]#
C'est pas terrible. J'ai quasiment le double : # hdparm -tT /dev/hda
/dev/hda: Timing cached reads: 1292 MB in 2.00 seconds = 645.78 MB/sec Timing buffered disk reads: 154 MB in 3.04 seconds = 50.60 MB/sec
Sur un disque IDE bas de gamme...
- Vérifier l'utilisation des bons pilotes dans le noyau... - Vérifier le réglage optimal des disques par hdparm.
Cela dit, même si ce n'est pas terrible, cela reste honorable et le problème ne vient peut-être pas de là.
-- Richard
*****
voilà ce que ça donne avec hdparm mais pour le scsi ça m'a l'air d'être
n'importe quoi car le sdb est un vieux 9 go avec un mini cache matériel et
le sda est un 36 go de "course" avec 8 mo de cache!?
__________________________________
[root@jp jp]# hdparm -tT /dev/sda1
/dev/sda1:
Timing buffer-cache reads: 544 MB in 2.01 seconds = 270.96 MB/sec
Timing buffered disk reads: 124 MB in 2.90 seconds = 42.81 MB/sec
[root@jp jp]# hdparm -tT /dev/sda5
/dev/sda5:
Timing buffer-cache reads: 588 MB in 2.00 seconds = 293.46 MB/sec
Timing buffered disk reads: 116 MB in 3.02 seconds = 38.42 MB/sec
[root@jp jp]# hdparm -tT /dev/sdb1
/dev/sdb1:
Timing buffer-cache reads: 556 MB in 2.00 seconds = 277.90 MB/sec
Timing buffered disk reads: 120 MB in 3.01 seconds = 39.86 MB/sec
[root@jp jp]#
C'est pas terrible. J'ai quasiment le double :
# hdparm -tT /dev/hda
/dev/hda:
Timing cached reads: 1292 MB in 2.00 seconds = 645.78 MB/sec
Timing buffered disk reads: 154 MB in 3.04 seconds = 50.60 MB/sec
Sur un disque IDE bas de gamme...
- Vérifier l'utilisation des bons pilotes dans le noyau...
- Vérifier le réglage optimal des disques par hdparm.
Cela dit, même si ce n'est pas terrible, cela reste honorable et le
problème ne vient peut-être pas de là.
***** voilà ce que ça donne avec hdparm mais pour le scsi ça m'a l'air d'être n'importe quoi car le sdb est un vieux 9 go avec un mini cache matériel et le sda est un 36 go de "course" avec 8 mo de cache!? __________________________________ [ jp]# hdparm -tT /dev/sda1
/dev/sda1: Timing buffer-cache reads: 544 MB in 2.01 seconds = 270.96 MB/sec Timing buffered disk reads: 124 MB in 2.90 seconds = 42.81 MB/sec [ jp]# hdparm -tT /dev/sda5
/dev/sda5: Timing buffer-cache reads: 588 MB in 2.00 seconds = 293.46 MB/sec Timing buffered disk reads: 116 MB in 3.02 seconds = 38.42 MB/sec [ jp]# hdparm -tT /dev/sdb1
/dev/sdb1: Timing buffer-cache reads: 556 MB in 2.00 seconds = 277.90 MB/sec Timing buffered disk reads: 120 MB in 3.01 seconds = 39.86 MB/sec [ jp]#
C'est pas terrible. J'ai quasiment le double : # hdparm -tT /dev/hda
/dev/hda: Timing cached reads: 1292 MB in 2.00 seconds = 645.78 MB/sec Timing buffered disk reads: 154 MB in 3.04 seconds = 50.60 MB/sec
Sur un disque IDE bas de gamme...
- Vérifier l'utilisation des bons pilotes dans le noyau... - Vérifier le réglage optimal des disques par hdparm.
Cela dit, même si ce n'est pas terrible, cela reste honorable et le problème ne vient peut-être pas de là.
-- Richard
Richard Delorme
bonjour à tous,
Tout est en REISERFS sur disque scsi Contrôleur scsi SYMBIOS 53c1010-33 Ultra3 Noyau SMP 2.6.8 (2 x 1 MHz) avec option preemptible kernel.
j'ai visiblement un gros souci de performance avec mes partitions reiserfs 3.6.
Pour gagner en performance, mais perdre un peu de place, on peut monter les partitions avec l'option notail.
Le seul autre disque est un NTFS+FAT32; quand je charge un fichier quelconque de plusieurs Mo ou plus c'est très lent sous REISERFS (plusieurs secondes pour une image tiff de 18 Mo par exemple). Par contre quand je le fais avec la partition NTFS c'est quasi instantané! J'ai essayé avec la FAT32 et idem c'est particulièrement rapide! (attention j'ai fait un tas de contre manipulations pour éviter les "erreurs d'appréciation" dues au cache disque) Je n'ai pas essayé avec une EXT3 car je n'ai pas envie de tout casser!
Pour les gros fichiers (image de 18 Mo), c'est plutôt xfs qu'il faudrait essayer.
De toute façon je trouve globalement les accès disque lents (ne serait-ce que lorsque je charge un simple éditeur de fichier).
Là c'est un autre problème, le chargement des exécutables et l'édition des liens dynamiques. Il existe un utilitaire, prelink, qui permet d'accélérer le chargement des programmes. La future version de gcc (4.0) devrait apporter de nouvelles options qui devrait encore améliorer ça et mettre linux au niveau de windows sur ce point.
-- Richard
bonjour à tous,
Tout est en REISERFS sur disque scsi
Contrôleur scsi SYMBIOS 53c1010-33 Ultra3
Noyau SMP 2.6.8 (2 x 1 MHz) avec option preemptible kernel.
j'ai visiblement un gros souci de performance avec mes partitions
reiserfs 3.6.
Pour gagner en performance, mais perdre un peu de place, on peut monter
les partitions avec l'option notail.
Le seul autre disque est un NTFS+FAT32; quand je charge un fichier
quelconque de plusieurs Mo ou plus c'est très lent sous REISERFS
(plusieurs secondes pour une image tiff de 18 Mo par exemple).
Par contre quand je le fais avec la partition NTFS c'est quasi
instantané! J'ai essayé avec la FAT32 et idem c'est particulièrement
rapide! (attention j'ai fait un tas de contre manipulations pour éviter
les "erreurs d'appréciation" dues au cache disque)
Je n'ai pas essayé avec une EXT3 car je n'ai pas envie de tout casser!
Pour les gros fichiers (image de 18 Mo), c'est plutôt xfs qu'il faudrait
essayer.
De toute façon je trouve globalement les accès disque lents (ne
serait-ce que lorsque je charge un simple éditeur de fichier).
Là c'est un autre problème, le chargement des exécutables et l'édition
des liens dynamiques. Il existe un utilitaire, prelink, qui permet
d'accélérer le chargement des programmes. La future version de gcc (4.0)
devrait apporter de nouvelles options qui devrait encore améliorer ça et
mettre linux au niveau de windows sur ce point.
Tout est en REISERFS sur disque scsi Contrôleur scsi SYMBIOS 53c1010-33 Ultra3 Noyau SMP 2.6.8 (2 x 1 MHz) avec option preemptible kernel.
j'ai visiblement un gros souci de performance avec mes partitions reiserfs 3.6.
Pour gagner en performance, mais perdre un peu de place, on peut monter les partitions avec l'option notail.
Le seul autre disque est un NTFS+FAT32; quand je charge un fichier quelconque de plusieurs Mo ou plus c'est très lent sous REISERFS (plusieurs secondes pour une image tiff de 18 Mo par exemple). Par contre quand je le fais avec la partition NTFS c'est quasi instantané! J'ai essayé avec la FAT32 et idem c'est particulièrement rapide! (attention j'ai fait un tas de contre manipulations pour éviter les "erreurs d'appréciation" dues au cache disque) Je n'ai pas essayé avec une EXT3 car je n'ai pas envie de tout casser!
Pour les gros fichiers (image de 18 Mo), c'est plutôt xfs qu'il faudrait essayer.
De toute façon je trouve globalement les accès disque lents (ne serait-ce que lorsque je charge un simple éditeur de fichier).
Là c'est un autre problème, le chargement des exécutables et l'édition des liens dynamiques. Il existe un utilitaire, prelink, qui permet d'accélérer le chargement des programmes. La future version de gcc (4.0) devrait apporter de nouvelles options qui devrait encore améliorer ça et mettre linux au niveau de windows sur ce point.
