En ce moment j'ai un Maxtor IDE 120Go 8 Mo. Je desire un 2e DD identique en
stockage mais je me tate entre un SATA et un IDE car je vais changer de
config. Les constructeurs sont :
- Maxtor
- IBM/Hitachi (dont je ne veux plus entendre parler -> 3 DD morts)
- Seagate
- Western Digital.
Sachant que le Maxtor SATA est au meme prix que l'IDE, les autres subissent
une augmentation approximative de 15 euros. Le jeu en vaut il la chandelle
et quelle marque choisir ?
C'est exact, en fait c'est dans ces cas que la machine rame alors même qu'il n'y a pas de charge CPU. Cependant ça n'est pas exclusivement liée à la 3Ware, mais aussi au PCI et au noyau : la limite est beaucoup plus haute avec un noyau 2.6.
En fait c'est normal, c'est que le kernel est préemptible avec la 2.6, donc la machine peut continuer à bosser pendant que la 3Ware vide sa queue :
http://www.kniggit.net/wwol26.html
One of the key improvements in Linux 2.6, is that the kernel is finally preemptible. In all previous versions of Linux, the kernel itself cannot be interrupted while it is processing. (On a system with multiple processors, this was true on a per-CPU basis.) Under Linux 2.6, the kernel now can be interrupted mid-task, so that other applications can continue to run even when something low-level and complicated is going on in the background.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <pan.2003.10.31.15.11.22.445846@ezglkhzglihzrhg.com>,
eflorac@ezglkhzglihzrhg.com disait...
C'est exact, en fait c'est dans ces cas que la machine rame alors même
qu'il n'y a pas de charge CPU. Cependant ça n'est pas exclusivement liée
à la 3Ware, mais aussi au PCI et au noyau : la limite est beaucoup plus
haute avec un noyau 2.6.
En fait c'est normal, c'est que le kernel est préemptible avec la 2.6,
donc la machine peut continuer à bosser pendant que la 3Ware vide sa
queue :
http://www.kniggit.net/wwol26.html
One of the key improvements in Linux 2.6, is that the kernel is finally
preemptible. In all previous versions of Linux, the kernel itself cannot
be interrupted while it is processing. (On a system with multiple
processors, this was true on a per-CPU basis.) Under Linux 2.6, the
kernel now can be interrupted mid-task, so that other applications can
continue to run even when something low-level and complicated is going on
in the background.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
C'est exact, en fait c'est dans ces cas que la machine rame alors même qu'il n'y a pas de charge CPU. Cependant ça n'est pas exclusivement liée à la 3Ware, mais aussi au PCI et au noyau : la limite est beaucoup plus haute avec un noyau 2.6.
En fait c'est normal, c'est que le kernel est préemptible avec la 2.6, donc la machine peut continuer à bosser pendant que la 3Ware vide sa queue :
http://www.kniggit.net/wwol26.html
One of the key improvements in Linux 2.6, is that the kernel is finally preemptible. In all previous versions of Linux, the kernel itself cannot be interrupted while it is processing. (On a system with multiple processors, this was true on a per-CPU basis.) Under Linux 2.6, the kernel now can be interrupted mid-task, so that other applications can continue to run even when something low-level and complicated is going on in the background.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Bd
Salut manu,
Le Fri, 31 Oct 2003 15:04:13 +0100, "Manu Clinton" écrivait:
et surtout n'achète pas un Hitachi
Marrant, parce que la conclusion du test ...etc J'ai donc du mal à suivre ta logique ???
du coup j'ai acheté ce disque il est reparti au vendeur le soir même a jamais marché
OK, je comprends mieux. Cela dit, sur UN problème, batir une généralité (même si je t'accorde que le fait d'être le bénéficiaire du problème rend forcément moins philosophe!), c'est peut être une vision un peu réduite, non ? 8-)
Cordialement, -- Bernard (NB: mon adresse de retour est valide. Ne rien y changer) (NB: This is a valid Reply-To. Do not remove anything) --
Salut manu,
Le Fri, 31 Oct 2003 15:04:13 +0100, "Manu Clinton"
<monopole@wanadoo.fr> écrivait:
et surtout n'achète pas un Hitachi
Marrant, parce que la conclusion du test ...etc
J'ai donc du mal à suivre ta logique ???
du coup j'ai acheté ce disque
il est reparti au vendeur le soir même
a jamais marché
OK, je comprends mieux. Cela dit, sur UN problème, batir une
généralité (même si je t'accorde que le fait d'être le bénéficiaire du
problème rend forcément moins philosophe!), c'est peut être une vision
un peu réduite, non ? 8-)
Cordialement,
--
Bernard
(NB: mon adresse de retour est valide. Ne rien y changer)
(NB: This is a valid Reply-To. Do not remove anything)
--
Le Fri, 31 Oct 2003 15:04:13 +0100, "Manu Clinton" écrivait:
et surtout n'achète pas un Hitachi
Marrant, parce que la conclusion du test ...etc J'ai donc du mal à suivre ta logique ???
du coup j'ai acheté ce disque il est reparti au vendeur le soir même a jamais marché
OK, je comprends mieux. Cela dit, sur UN problème, batir une généralité (même si je t'accorde que le fait d'être le bénéficiaire du problème rend forcément moins philosophe!), c'est peut être une vision un peu réduite, non ? 8-)
Cordialement, -- Bernard (NB: mon adresse de retour est valide. Ne rien y changer) (NB: This is a valid Reply-To. Do not remove anything) --
Francois Petillon
Quel est le FS utilisé? ext2
Ah, et tu en es content? Il était systématiquement loin derrière dans
tous mes tests...
Faudra qu'on m'explique comment un FS journalisé peut être plus efficace en débit qu'un FS non journalisé (enfin, dans le cas où le journal est sur le même disque que les données). Tant que je ne trouve pas de cartes nvram reconnues par linux à un prix "abordable", je fais une croix sur les FS journalisées sur ce type d'application.
Ça ne change rien sur le fond : acceder à 300 Ko de données entrainera de facto 5 à 6 seeks et que c'est là le facteur limitant. ?? si tu as écrit les 300 Ko d'un seul tenant, tu les liras d'un seul
Parce que les blocs RAID font 64Ko et que cela signifie qu'une lecture de 300 Ko necessite de lire 5 à 6 blocs sur autant de disques durs et par conséquent entrainera le même nombre de seeks.
François
Quel est le FS utilisé?
ext2
Ah, et tu en es content? Il était systématiquement loin derrière dans
tous mes tests...
Faudra qu'on m'explique comment un FS journalisé peut être plus efficace
en débit qu'un FS non journalisé (enfin, dans le cas où le journal est
sur le même disque que les données). Tant que je ne trouve pas de cartes
nvram reconnues par linux à un prix "abordable", je fais une croix sur
les FS journalisées sur ce type d'application.
Ça ne change rien sur le fond : acceder à 300 Ko de données entrainera
de facto 5 à 6 seeks et que c'est là le facteur limitant.
?? si tu as écrit les 300 Ko d'un seul tenant, tu les liras d'un seul
Parce que les blocs RAID font 64Ko et que cela signifie qu'une lecture
de
300 Ko necessite de lire 5 à 6 blocs sur autant de disques durs et par
conséquent entrainera le même nombre de seeks.
Ah, et tu en es content? Il était systématiquement loin derrière dans
tous mes tests...
Faudra qu'on m'explique comment un FS journalisé peut être plus efficace en débit qu'un FS non journalisé (enfin, dans le cas où le journal est sur le même disque que les données). Tant que je ne trouve pas de cartes nvram reconnues par linux à un prix "abordable", je fais une croix sur les FS journalisées sur ce type d'application.
Ça ne change rien sur le fond : acceder à 300 Ko de données entrainera de facto 5 à 6 seeks et que c'est là le facteur limitant. ?? si tu as écrit les 300 Ko d'un seul tenant, tu les liras d'un seul
Parce que les blocs RAID font 64Ko et que cela signifie qu'une lecture de 300 Ko necessite de lire 5 à 6 blocs sur autant de disques durs et par conséquent entrainera le même nombre de seeks.
François
Francois Petillon
C'est exact, en fait c'est dans ces cas que la machine rame alors même qu'il n'y a pas de charge CPU. Cependant ça n'est pas exclusivement liée à la 3Ware, mais aussi au PCI et au noyau : la limite est beaucoup plus haute avec un noyau 2.6.
À priori, rien n'empeche le driver de se faire une queue de commandes "de débordement" en mémoire. 254 commandes sur 8 disques durs, ça fait un peu moins de 32 commandes par disque soit moins que ce qui peut être traité en une seconde. Pour le kernel 2.6, le probleme est simplement caché.
François
C'est exact, en fait c'est dans ces cas que la machine rame alors même
qu'il n'y a pas de charge CPU. Cependant ça n'est pas exclusivement liée
à la 3Ware, mais aussi au PCI et au noyau : la limite est beaucoup plus
haute avec un noyau 2.6.
À priori, rien n'empeche le driver de se faire une queue de commandes
"de débordement" en mémoire. 254 commandes sur 8 disques durs, ça fait
un peu moins de 32 commandes par disque soit moins que ce qui peut être
traité en une seconde. Pour le kernel 2.6, le probleme est simplement
caché.
C'est exact, en fait c'est dans ces cas que la machine rame alors même qu'il n'y a pas de charge CPU. Cependant ça n'est pas exclusivement liée à la 3Ware, mais aussi au PCI et au noyau : la limite est beaucoup plus haute avec un noyau 2.6.
À priori, rien n'empeche le driver de se faire une queue de commandes "de débordement" en mémoire. 254 commandes sur 8 disques durs, ça fait un peu moins de 32 commandes par disque soit moins que ce qui peut être traité en une seconde. Pour le kernel 2.6, le probleme est simplement caché.
François
Nicolas Chuche
Francois Petillon disait le 11/03/03 que :
Faudra qu'on m'explique comment un FS journalisé peut être plus efficace en débit qu'un FS non journalisé (enfin, dans le cas où le journal est sur le même disque que les données).
Pour les écritures j'avais lu un truc comme quoi c'était plus rapide dans certains cas parce que tout était, dans un premier temps, écrit dans le journal donc la tête du disque n'avait pas à se balader partout.
Francois Petillon <fantec@proxad.net> disait le 11/03/03 que :
Faudra qu'on m'explique comment un FS journalisé peut être plus efficace
en débit qu'un FS non journalisé (enfin, dans le cas où le journal est
sur le même disque que les données).
Pour les écritures j'avais lu un truc comme quoi c'était plus rapide
dans certains cas parce que tout était, dans un premier temps, écrit
dans le journal donc la tête du disque n'avait pas à se balader
partout.
Faudra qu'on m'explique comment un FS journalisé peut être plus efficace en débit qu'un FS non journalisé (enfin, dans le cas où le journal est sur le même disque que les données).
Pour les écritures j'avais lu un truc comme quoi c'était plus rapide dans certains cas parce que tout était, dans un premier temps, écrit dans le journal donc la tête du disque n'avait pas à se balader partout.
Francois Petillon
Pour les écritures j'avais lu un truc comme quoi c'était plus rapide dans certains cas parce que tout était, dans un premier temps, écrit dans le journal donc la tête du disque n'avait pas à se balader partout.
Oui, dans le cas de créations/destructions de fichiers/repertoires/etc. Mais pas pour de l'écriture de gros fichiers comme c'est le cas pour les news.
François
Pour les écritures j'avais lu un truc comme quoi c'était plus rapide
dans certains cas parce que tout était, dans un premier temps, écrit
dans le journal donc la tête du disque n'avait pas à se balader
partout.
Oui, dans le cas de créations/destructions de fichiers/repertoires/etc.
Mais pas pour de l'écriture de gros fichiers comme c'est le cas pour
les news.
Pour les écritures j'avais lu un truc comme quoi c'était plus rapide dans certains cas parce que tout était, dans un premier temps, écrit dans le journal donc la tête du disque n'avait pas à se balader partout.
Oui, dans le cas de créations/destructions de fichiers/repertoires/etc. Mais pas pour de l'écriture de gros fichiers comme c'est le cas pour les news.
François
Emmanuel Florac
Dans article , disait...
Faudra qu'on m'explique comment un FS journalisé peut être plus efficace en débit qu'un FS non journalisé (enfin, dans le cas où le journal est sur le même disque que les données).
Parce que XFS est plus efficace que ext2, journal ou pas. Je ne me suis pas penché sur le détail du pourquoi et du comment, mais c'est un fait, il va plus vite et il est optimisé précisément pour ça. Les perfs de XFS "collent" aux perfs du disque sous-jacent, alors qu'ext2 en est très loin. En plus on peut utiliser XFS GRIO sous Linux maintenant, c'est à dire avoir un débit disque _garanti_ et _temps-réel_ sur les disques.
Tant que je ne trouve pas de cartes nvram reconnues par linux à un prix "abordable", je fais une croix sur les FS journalisées sur ce type d'application.
A mon avis tu fais erreur, mais bon...
Parce que les blocs RAID font 64Ko et que cela signifie qu'une lecture de 300 Ko necessite de lire 5 à 6 blocs sur autant de disques durs et par conséquent entrainera le même nombre de seeks.
Exact, au temps pour moi :) Et en miroir, ça ne marcherait pas mieux pour toi? D'autant que les perfs en écriture sont bien meilleures.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <3FA65F08.14754F3A@proxad.net>, fantec@proxad.net disait...
Faudra qu'on m'explique comment un FS journalisé peut être plus efficace
en débit qu'un FS non journalisé (enfin, dans le cas où le journal est
sur le même disque que les données).
Parce que XFS est plus efficace que ext2, journal ou pas. Je ne me suis
pas penché sur le détail du pourquoi et du comment, mais c'est un fait,
il va plus vite et il est optimisé précisément pour ça. Les perfs de XFS
"collent" aux perfs du disque sous-jacent, alors qu'ext2 en est très
loin. En plus on peut utiliser XFS GRIO sous Linux maintenant, c'est à
dire avoir un débit disque _garanti_ et _temps-réel_ sur les disques.
Tant que je ne trouve pas de cartes
nvram reconnues par linux à un prix "abordable", je fais une croix sur
les FS journalisées sur ce type d'application.
A mon avis tu fais erreur, mais bon...
Parce que les blocs RAID font 64Ko et que cela signifie qu'une lecture
de
300 Ko necessite de lire 5 à 6 blocs sur autant de disques durs et par
conséquent entrainera le même nombre de seeks.
Exact, au temps pour moi :) Et en miroir, ça ne marcherait pas mieux pour
toi? D'autant que les perfs en écriture sont bien meilleures.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Faudra qu'on m'explique comment un FS journalisé peut être plus efficace en débit qu'un FS non journalisé (enfin, dans le cas où le journal est sur le même disque que les données).
Parce que XFS est plus efficace que ext2, journal ou pas. Je ne me suis pas penché sur le détail du pourquoi et du comment, mais c'est un fait, il va plus vite et il est optimisé précisément pour ça. Les perfs de XFS "collent" aux perfs du disque sous-jacent, alors qu'ext2 en est très loin. En plus on peut utiliser XFS GRIO sous Linux maintenant, c'est à dire avoir un débit disque _garanti_ et _temps-réel_ sur les disques.
Tant que je ne trouve pas de cartes nvram reconnues par linux à un prix "abordable", je fais une croix sur les FS journalisées sur ce type d'application.
A mon avis tu fais erreur, mais bon...
Parce que les blocs RAID font 64Ko et que cela signifie qu'une lecture de 300 Ko necessite de lire 5 à 6 blocs sur autant de disques durs et par conséquent entrainera le même nombre de seeks.
Exact, au temps pour moi :) Et en miroir, ça ne marcherait pas mieux pour toi? D'autant que les perfs en écriture sont bien meilleures.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Emmanuel Florac
Dans article , disait...
À priori, rien n'empeche le driver de se faire une queue de commandes "de débordement" en mémoire. 254 commandes sur 8 disques durs, ça fait un peu moins de 32 commandes par disque soit moins que ce qui peut être traité en une seconde. Pour le kernel 2.6, le probleme est simplement caché.
Non, je pense que sous 2.4 la tâche noyau ne rend pas la main (mauvais driver, patcher driver :), mais sous 2.6 les tâches noyaux sont préemtibles, ce qui fait mieux que masquer le problème mais le règle effectivement...
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <3FA66311.CE8157B9@proxad.net>, fantec@proxad.net disait...
À priori, rien n'empeche le driver de se faire une queue de commandes
"de débordement" en mémoire. 254 commandes sur 8 disques durs, ça fait
un peu moins de 32 commandes par disque soit moins que ce qui peut être
traité en une seconde. Pour le kernel 2.6, le probleme est simplement
caché.
Non, je pense que sous 2.4 la tâche noyau ne rend pas la main (mauvais
driver, patcher driver :), mais sous 2.6 les tâches noyaux sont
préemtibles, ce qui fait mieux que masquer le problème mais le règle
effectivement...
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
À priori, rien n'empeche le driver de se faire une queue de commandes "de débordement" en mémoire. 254 commandes sur 8 disques durs, ça fait un peu moins de 32 commandes par disque soit moins que ce qui peut être traité en une seconde. Pour le kernel 2.6, le probleme est simplement caché.
Non, je pense que sous 2.4 la tâche noyau ne rend pas la main (mauvais driver, patcher driver :), mais sous 2.6 les tâches noyaux sont préemtibles, ce qui fait mieux que masquer le problème mais le règle effectivement...
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
