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 ?
Le 30 Oct 2003 18:42:26 GMT, loict+ (Loic Tortay) a écrit:
Jusqu'à présent, quelque soit l'HSM utilisé SAM/FS, Storage Migrator, HPSS, etc... celui-ci utilisait généralement deux niveaux de stockage : disques et cartouches.
Avec HPSS on peut mettre autant de niveaux que l'on souhaite.
D'ailleurs, l'un des deux sites français où HPSS est utilisé (pas le mien, l'autre), a deux niveaux de bandes (9840 et LTO2).
Bonjour Loic,
Dans ce groupe de discussion "tous publics", je précisais "généralement" car avant l'arrivée des baies IDE ou SATA et des bandes capacitives LTO2 ou 9940B, il n'y avait pas forcément un très grand intérêt économique à multiplier les niveaux de stockage même si un HSM comme HPSS pouvait gérer plus de deux niveaux.
En revanche, avec la panoplie de moyens de stockage disponible aujourd'hui, cela devient de plus en plus interressant et pas seulement pour les gros centres de calcul.
Pour preuve, quelques sites en dehors du monde restreint des centres scientifiques envisagent ou commencent à mettre en oeuvre des architectures à 3 ou 4 niveaux utilisant des baies IDE ou SATA pour répondre par exemple à des contraintes d'archivage.
Dans ce cas, il faut bien cibler les applications qui utiliseront ces baies car les performances obtenues seront en retrait par rapport à du FC comme on pu le constater certains admins qui ont fait des tests comparatifs entre ces technomogies................ ;-)
Cordialement. Didier G.
Pour répondre par mail, enlevez NOSPAM- dans l'adresse. To answer by mail, remove NOSPAM- in address.
Le 30 Oct 2003 18:42:26 GMT, loict+usenet@bougon.net (Loic Tortay) a
écrit:
Jusqu'à présent, quelque soit l'HSM utilisé SAM/FS, Storage Migrator,
HPSS, etc... celui-ci utilisait généralement deux niveaux de stockage :
disques et cartouches.
Avec HPSS on peut mettre autant de niveaux que l'on souhaite.
D'ailleurs, l'un des deux sites français où HPSS est utilisé (pas le
mien, l'autre), a deux niveaux de bandes (9840 et LTO2).
Bonjour Loic,
Dans ce groupe de discussion "tous publics", je précisais
"généralement" car avant l'arrivée des baies IDE ou SATA et des
bandes capacitives LTO2 ou 9940B, il n'y avait pas forcément un très
grand intérêt économique à multiplier les niveaux de stockage même si
un HSM comme HPSS pouvait gérer plus de deux niveaux.
En revanche, avec la panoplie de moyens de stockage disponible
aujourd'hui, cela devient de plus en plus interressant et pas
seulement pour les gros centres de calcul.
Pour preuve, quelques sites en dehors du monde restreint des centres
scientifiques envisagent ou commencent à mettre en oeuvre des
architectures à 3 ou 4 niveaux utilisant des baies IDE ou SATA pour
répondre par exemple à des contraintes d'archivage.
Dans ce cas, il faut bien cibler les applications qui utiliseront ces
baies car les performances obtenues seront en retrait par rapport à
du FC comme on pu le constater certains admins qui ont fait des tests
comparatifs entre ces technomogies................ ;-)
Cordialement. Didier G.
Pour répondre par mail, enlevez NOSPAM- dans l'adresse.
To answer by mail, remove NOSPAM- in address.
Le 30 Oct 2003 18:42:26 GMT, loict+ (Loic Tortay) a écrit:
Jusqu'à présent, quelque soit l'HSM utilisé SAM/FS, Storage Migrator, HPSS, etc... celui-ci utilisait généralement deux niveaux de stockage : disques et cartouches.
Avec HPSS on peut mettre autant de niveaux que l'on souhaite.
D'ailleurs, l'un des deux sites français où HPSS est utilisé (pas le mien, l'autre), a deux niveaux de bandes (9840 et LTO2).
Bonjour Loic,
Dans ce groupe de discussion "tous publics", je précisais "généralement" car avant l'arrivée des baies IDE ou SATA et des bandes capacitives LTO2 ou 9940B, il n'y avait pas forcément un très grand intérêt économique à multiplier les niveaux de stockage même si un HSM comme HPSS pouvait gérer plus de deux niveaux.
En revanche, avec la panoplie de moyens de stockage disponible aujourd'hui, cela devient de plus en plus interressant et pas seulement pour les gros centres de calcul.
Pour preuve, quelques sites en dehors du monde restreint des centres scientifiques envisagent ou commencent à mettre en oeuvre des architectures à 3 ou 4 niveaux utilisant des baies IDE ou SATA pour répondre par exemple à des contraintes d'archivage.
Dans ce cas, il faut bien cibler les applications qui utiliseront ces baies car les performances obtenues seront en retrait par rapport à du FC comme on pu le constater certains admins qui ont fait des tests comparatifs entre ces technomogies................ ;-)
Cordialement. Didier G.
Pour répondre par mail, enlevez NOSPAM- dans l'adresse. To answer by mail, remove NOSPAM- in address.
Emmanuel Florac
Dans article <3fa10265$0$29490$, NOSPAM- disait...
Aujourd'hui, vu les volumes à gérer et le coût des nouveaux systèmes disques basés sur de l'IDE ou du SATA (coût au TB pour de grosses configurations qui se rapproche du coût sur cartouche automatisée performante), on voit (quelques) sites en passe d'évoluer à l'horizon 2004/2005 vers des architectures à trois voir quatre niveaux avec des SLA différents en fonctions du type de données et de l'âge de celles-ci.
<pub>Au fait, j'espère qu'en février je pourrai montrer une préversion de mon HSM multiniveau sur Linux Solutions :) </pub>
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <3fa10265$0$29490$afc38c87@news.easynet.fr>, NOSPAM-
didierg987@netcourrier.com disait...
Aujourd'hui, vu les volumes à gérer et le coût des nouveaux systèmes
disques basés sur de l'IDE ou du SATA (coût au TB pour de grosses
configurations qui se rapproche du coût sur cartouche automatisée
performante), on voit (quelques) sites en passe d'évoluer à l'horizon
2004/2005 vers des architectures à trois voir quatre niveaux avec des
SLA différents en fonctions du type de données et de l'âge de celles-ci.
<pub>Au fait, j'espère qu'en février je pourrai montrer une préversion de
mon HSM multiniveau sur Linux Solutions :) </pub>
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <3fa10265$0$29490$, NOSPAM- disait...
Aujourd'hui, vu les volumes à gérer et le coût des nouveaux systèmes disques basés sur de l'IDE ou du SATA (coût au TB pour de grosses configurations qui se rapproche du coût sur cartouche automatisée performante), on voit (quelques) sites en passe d'évoluer à l'horizon 2004/2005 vers des architectures à trois voir quatre niveaux avec des SLA différents en fonctions du type de données et de l'âge de celles-ci.
<pub>Au fait, j'espère qu'en février je pourrai montrer une préversion de mon HSM multiniveau sur Linux Solutions :) </pub>
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Emmanuel Florac
Dans article , NOSPAM- disait...
Dans ce cas, il faut bien cibler les applications qui utiliseront ces baies car les performances obtenues seront en retrait par rapport à du FC comme on pu le constater certains admins qui ont fait des tests comparatifs entre ces technomogies................ ;-)
Tiens, aujourd'hui j'ai fait des benchs sous Linux (encore). J'ai testé un certain nombre de disques : un ATA 80 Go, des Cheetah 10000 tours FC 36 Go de deux types différents. les perfs sont les suivantes :
Cheetah 336607FC : 67Mo/s en lecture, 42Mo/s en écriture. Cheetah 336704FC : 54Mo/s en lecture, 35 Mo/s en écriture. Maxtor 80 Go de base : 49 Mo/s en lecture, 35 Mo/s en écriture.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <3at2qv4ciafp4sejkf030qpddfjelhlb7c@4ax.com>, NOSPAM-
didierg987@netcourrier.com disait...
Dans ce cas, il faut bien cibler les applications qui utiliseront ces
baies car les performances obtenues seront en retrait par rapport à
du FC comme on pu le constater certains admins qui ont fait des tests
comparatifs entre ces technomogies................ ;-)
Tiens, aujourd'hui j'ai fait des benchs sous Linux (encore). J'ai testé
un certain nombre de disques : un ATA 80 Go, des Cheetah 10000 tours FC
36 Go de deux types différents. les perfs sont les suivantes :
Cheetah 336607FC : 67Mo/s en lecture, 42Mo/s en écriture.
Cheetah 336704FC : 54Mo/s en lecture, 35 Mo/s en écriture.
Maxtor 80 Go de base : 49 Mo/s en lecture, 35 Mo/s en écriture.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans ce cas, il faut bien cibler les applications qui utiliseront ces baies car les performances obtenues seront en retrait par rapport à du FC comme on pu le constater certains admins qui ont fait des tests comparatifs entre ces technomogies................ ;-)
Tiens, aujourd'hui j'ai fait des benchs sous Linux (encore). J'ai testé un certain nombre de disques : un ATA 80 Go, des Cheetah 10000 tours FC 36 Go de deux types différents. les perfs sont les suivantes :
Cheetah 336607FC : 67Mo/s en lecture, 42Mo/s en écriture. Cheetah 336704FC : 54Mo/s en lecture, 35 Mo/s en écriture. Maxtor 80 Go de base : 49 Mo/s en lecture, 35 Mo/s en écriture.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Emmanuel Florac
Dans article , disait...
Sur une configuration en RAID5 avec des accès via mmap(avec un madvise en MADV_SEQUENTIAL), les serveurs pouvaient sortir environ 90 Mbps. En changeant les madvises en MADV_WILLNEED on passe à 165 Mbps (le facteur limitatif concerne la taille des blocs de 64Ko dûe au RAID5 des cartes 3Ware alors que l'article moyen fait 300 Ko dans les alt.binaries).
Quel est le FS utilisé? Selon le FS et la taille des fichiers, la perf varie quasiment du simple au double entre reiser et xfs! Autre piste : en mettant deux cartes 3ware, tu peux striper les deux volumes logiques et adapter la granularité de ton bloc au niveau de LVM (ou de linux RAID). Par contre il faudrait sans doute un CPU un poil plus puissant pour bien en profiter: aujourd'hui lors de tests avec un PIII 1Ghz, je touchais plus souvent la limite du CPU que des disques FC derrière. A contrario, avec un P4 2.4Ghz, on sature complètement le bus PCI sans vraiment mettre le CPU à genoux. Pour finir, je sais que ce n'est pas raisonnable pour une exploitation de ce type, mais j'ai fait des tests en 2.6.0-test7 et ça s'annonce TRES TRES BIEN! :)
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <pan.2003.10.30.11.42.26.845673@proxad.net>,
fantec@proxad.net disait...
Sur une configuration en RAID5 avec des accès via mmap(avec un madvise en
MADV_SEQUENTIAL), les serveurs pouvaient sortir environ 90 Mbps. En
changeant les madvises en MADV_WILLNEED on passe à 165 Mbps (le facteur
limitatif concerne la taille des blocs de 64Ko dûe au RAID5 des cartes
3Ware alors que l'article moyen fait 300 Ko dans les alt.binaries).
Quel est le FS utilisé? Selon le FS et la taille des fichiers, la perf
varie quasiment du simple au double entre reiser et xfs!
Autre piste : en mettant deux cartes 3ware, tu peux striper les deux
volumes logiques et adapter la granularité de ton bloc au niveau de LVM
(ou de linux RAID). Par contre il faudrait sans doute un CPU un poil plus
puissant pour bien en profiter: aujourd'hui lors de tests avec un PIII
1Ghz, je touchais plus souvent la limite du CPU que des disques FC
derrière. A contrario, avec un P4 2.4Ghz, on sature complètement le bus
PCI sans vraiment mettre le CPU à genoux.
Pour finir, je sais que ce n'est pas raisonnable pour une exploitation de
ce type, mais j'ai fait des tests en 2.6.0-test7 et ça s'annonce TRES
TRES BIEN! :)
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Sur une configuration en RAID5 avec des accès via mmap(avec un madvise en MADV_SEQUENTIAL), les serveurs pouvaient sortir environ 90 Mbps. En changeant les madvises en MADV_WILLNEED on passe à 165 Mbps (le facteur limitatif concerne la taille des blocs de 64Ko dûe au RAID5 des cartes 3Ware alors que l'article moyen fait 300 Ko dans les alt.binaries).
Quel est le FS utilisé? Selon le FS et la taille des fichiers, la perf varie quasiment du simple au double entre reiser et xfs! Autre piste : en mettant deux cartes 3ware, tu peux striper les deux volumes logiques et adapter la granularité de ton bloc au niveau de LVM (ou de linux RAID). Par contre il faudrait sans doute un CPU un poil plus puissant pour bien en profiter: aujourd'hui lors de tests avec un PIII 1Ghz, je touchais plus souvent la limite du CPU que des disques FC derrière. A contrario, avec un P4 2.4Ghz, on sature complètement le bus PCI sans vraiment mettre le CPU à genoux. Pour finir, je sais que ce n'est pas raisonnable pour une exploitation de ce type, mais j'ai fait des tests en 2.6.0-test7 et ça s'annonce TRES TRES BIEN! :)
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Emmanuel Florac
Dans article , disait...
Bof, je crois qu'on en a discuté sur le forum Stockage. De tels specs correspondent à un environement monotache (peu de clients simultannés) sur des lectures séquentielles.
Bien entendu. Ca correspond bien aux gens pour qui je construis des solutions à l'heure actuelle, beaucoup d'applications de type vidéo ou serveur de gros fichiers à grosse capacité. Néammoins il ne faut pas négliger l'influence du FS : on a un nombre d'IO colossal en reiser mais des débits médiocres, a contrario un débit effarant et des IO ridicules en XFS.
Mais promis, dès que j'ai un peu de temps je ferai des tests dans la même configuration avec plusieurs centaines de processus, pour voir comment ça se tient. Mais j'ai confiance, les cartes 3Ware font du CTQ, donc il n'est pas dit qu'il y ait une grosse différence avec un contrôleur SCSI standard genre Mylex ou PERC (en fait, je suis presque certain qu'il n'y en a pas).
Pour ma part, j'ai observé 10% de pertes sur les disques mais uniquement sur les deux permières semaines. Plus de pertes par la suite.
Oui, le disque que j'ai perdu a cassé dès le premier jour d'utilisation :)
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <pan.2003.10.30.11.27.06.404342@proxad.net>,
fantec@proxad.net disait...
Bof, je crois qu'on en a discuté sur le forum Stockage. De tels specs
correspondent à un environement monotache (peu de clients simultannés)
sur des lectures séquentielles.
Bien entendu. Ca correspond bien aux gens pour qui je construis des
solutions à l'heure actuelle, beaucoup d'applications de type vidéo ou
serveur de gros fichiers à grosse capacité.
Néammoins il ne faut pas négliger l'influence du FS : on a un nombre d'IO
colossal en reiser mais des débits médiocres, a contrario un débit
effarant et des IO ridicules en XFS.
Mais promis, dès que j'ai un peu de temps je ferai des tests dans la même
configuration avec plusieurs centaines de processus, pour voir comment ça
se tient. Mais j'ai confiance, les cartes 3Ware font du CTQ, donc il
n'est pas dit qu'il y ait une grosse différence avec un contrôleur SCSI
standard genre Mylex ou PERC (en fait, je suis presque certain qu'il n'y
en a pas).
Pour ma part, j'ai observé 10% de pertes sur les disques mais uniquement
sur les deux permières semaines. Plus de pertes par la suite.
Oui, le disque que j'ai perdu a cassé dès le premier jour d'utilisation
:)
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Bof, je crois qu'on en a discuté sur le forum Stockage. De tels specs correspondent à un environement monotache (peu de clients simultannés) sur des lectures séquentielles.
Bien entendu. Ca correspond bien aux gens pour qui je construis des solutions à l'heure actuelle, beaucoup d'applications de type vidéo ou serveur de gros fichiers à grosse capacité. Néammoins il ne faut pas négliger l'influence du FS : on a un nombre d'IO colossal en reiser mais des débits médiocres, a contrario un débit effarant et des IO ridicules en XFS.
Mais promis, dès que j'ai un peu de temps je ferai des tests dans la même configuration avec plusieurs centaines de processus, pour voir comment ça se tient. Mais j'ai confiance, les cartes 3Ware font du CTQ, donc il n'est pas dit qu'il y ait une grosse différence avec un contrôleur SCSI standard genre Mylex ou PERC (en fait, je suis presque certain qu'il n'y en a pas).
Pour ma part, j'ai observé 10% de pertes sur les disques mais uniquement sur les deux permières semaines. Plus de pertes par la suite.
Oui, le disque que j'ai perdu a cassé dès le premier jour d'utilisation :)
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Francois Petillon
On Fri, 31 Oct 2003 00:48:03 +0100, Emmanuel Florac wrote:
Quel est le FS utilisé?
ext2
Autre piste : en mettant deux cartes 3ware, tu peux striper les deux volumes logiques et adapter la granularité de ton bloc au niveau de LVM (ou de linux RAID).
Ç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.
Pour finir, je sais que ce n'est pas raisonnable pour une exploitation de ce type, mais j'ai fait des tests en 2.6.0-test7 et ça s'annonce TRES TRES BIEN! :)
si et seulement si la gestion du buffer-cache et de l'antelecture est adapté à l'application que tu fait tourner.
François
On Fri, 31 Oct 2003 00:48:03 +0100, Emmanuel Florac wrote:
Quel est le FS utilisé?
ext2
Autre piste : en mettant deux cartes 3ware, tu peux striper les deux
volumes logiques et adapter la granularité de ton bloc au niveau de LVM
(ou de linux RAID).
Ç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.
Pour finir, je sais que ce n'est pas raisonnable pour une exploitation de
ce type, mais j'ai fait des tests en 2.6.0-test7 et ça s'annonce TRES
TRES BIEN! :)
si et seulement si la gestion du buffer-cache et de l'antelecture
est adapté à l'application que tu fait tourner.
On Fri, 31 Oct 2003 00:48:03 +0100, Emmanuel Florac wrote:
Quel est le FS utilisé?
ext2
Autre piste : en mettant deux cartes 3ware, tu peux striper les deux volumes logiques et adapter la granularité de ton bloc au niveau de LVM (ou de linux RAID).
Ç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.
Pour finir, je sais que ce n'est pas raisonnable pour une exploitation de ce type, mais j'ai fait des tests en 2.6.0-test7 et ça s'annonce TRES TRES BIEN! :)
si et seulement si la gestion du buffer-cache et de l'antelecture est adapté à l'application que tu fait tourner.
François
Francois Petillon
On Fri, 31 Oct 2003 00:55:17 +0100, Emmanuel Florac wrote:
Mais j'ai confiance, les cartes 3Ware font du CTQ, donc il n'est pas dit qu'il y ait une grosse différence avec un contrôleur SCSI standard genre Mylex ou PERC (en fait, je suis presque certain qu'il n'y en a pas).
Je confirme l'efficacité du CTQ des 3Ware (les perfs continuent à grimper même lorsque le systeme disque semble saturé grace à l'optimisation des déplacements des tetes). Seul reproche que je lui ferais concerne la taille de la queue (255 commandes) et le comportement du systeme une fois que cette queue est remplie (j'ai l'impression que le kernel attend qu'une entrée soit libérée pour stocker la suivante et passer en mode utilisateur).
François
On Fri, 31 Oct 2003 00:55:17 +0100, Emmanuel Florac wrote:
Mais j'ai confiance, les cartes 3Ware font du CTQ, donc il
n'est pas dit qu'il y ait une grosse différence avec un contrôleur SCSI
standard genre Mylex ou PERC (en fait, je suis presque certain qu'il n'y
en a pas).
Je confirme l'efficacité du CTQ des 3Ware (les perfs continuent à grimper
même lorsque le systeme disque semble saturé grace à l'optimisation des
déplacements des tetes). Seul reproche que je lui ferais concerne la
taille de la queue (255 commandes) et le comportement du systeme une fois
que cette queue est remplie (j'ai l'impression que le kernel attend
qu'une entrée soit libérée pour stocker la suivante et passer en mode
utilisateur).
On Fri, 31 Oct 2003 00:55:17 +0100, Emmanuel Florac wrote:
Mais j'ai confiance, les cartes 3Ware font du CTQ, donc il n'est pas dit qu'il y ait une grosse différence avec un contrôleur SCSI standard genre Mylex ou PERC (en fait, je suis presque certain qu'il n'y en a pas).
Je confirme l'efficacité du CTQ des 3Ware (les perfs continuent à grimper même lorsque le systeme disque semble saturé grace à l'optimisation des déplacements des tetes). Seul reproche que je lui ferais concerne la taille de la queue (255 commandes) et le comportement du systeme une fois que cette queue est remplie (j'ai l'impression que le kernel attend qu'une entrée soit libérée pour stocker la suivante et passer en mode utilisateur).
François
Manu Clinton
"Bd" a écrit dans le message de news:
Salut,
Le Wed, 29 Oct 2003 19:47:10 +0100, "Manu Clinton" écrivait:
va faire un tour ici :
http://www.hardware.fr/articles/480/page1.html
et surtout n'achète pas un Hitachi
Marrant, parce que la conclusion du test auquel ton lien renvoie est la suivante:
"Si il y a bien un disque qui tire son épingle du jeu, c'est le Deskstar 7K250 d'Hitachi".
J'ai donc du mal à suivre ta logique ???
vi du coup j'ai acheté ce disque il est reparti au vendeur le soir même a jamais marché c'est super véloce Hitachi.... quand ça marche :-)
-- MC
"Bd" <nospamplease@ifrance.com> a écrit dans le message de
news:n2e0qv8sn9kchqe87eci3cgqfmbokm0i4b@4ax.com...
Salut,
Le Wed, 29 Oct 2003 19:47:10 +0100, "Manu Clinton"
<monopole@wanadoo.fr> écrivait:
va faire un tour ici :
http://www.hardware.fr/articles/480/page1.html
et surtout n'achète pas un Hitachi
Marrant, parce que la conclusion du test auquel ton lien renvoie est
la suivante:
"Si il y a bien un disque qui tire son épingle du jeu, c'est le
Deskstar 7K250 d'Hitachi".
J'ai donc du mal à suivre ta logique ???
vi
du coup j'ai acheté ce disque
il est reparti au vendeur le soir même
a jamais marché
c'est super véloce Hitachi....
quand ça marche :-)
Le Wed, 29 Oct 2003 19:47:10 +0100, "Manu Clinton" écrivait:
va faire un tour ici :
http://www.hardware.fr/articles/480/page1.html
et surtout n'achète pas un Hitachi
Marrant, parce que la conclusion du test auquel ton lien renvoie est la suivante:
"Si il y a bien un disque qui tire son épingle du jeu, c'est le Deskstar 7K250 d'Hitachi".
J'ai donc du mal à suivre ta logique ???
vi du coup j'ai acheté ce disque il est reparti au vendeur le soir même a jamais marché c'est super véloce Hitachi.... quand ça marche :-)
-- MC
Emmanuel Florac
Le Fri, 31 Oct 2003 11:55:07 +0100, Francois Petillon écrivait:
Seul reproche que je lui ferais concerne la taille de la queue (255 commandes) et le comportement du systeme une fois que cette queue est remplie (j'ai l'impression que le kernel attend qu'une entrée soit libérée pour stocker la suivante et passer en mode utilisateur).
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.
-- on passe la moitié de son temps à refaire ce que l'on n'a pas eu le temps de faire correctement. Loi de Myers.
Le Fri, 31 Oct 2003 11:55:07 +0100, Francois Petillon écrivait:
Seul reproche que je lui ferais concerne la
taille de la queue (255 commandes) et le comportement du systeme une fois
que cette queue est remplie (j'ai l'impression que le kernel attend
qu'une entrée soit libérée pour stocker la suivante et passer en mode
utilisateur).
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.
--
on passe la moitié de son temps à refaire ce que l'on n'a pas eu le
temps de faire correctement.
Loi de Myers.
Le Fri, 31 Oct 2003 11:55:07 +0100, Francois Petillon écrivait:
Seul reproche que je lui ferais concerne la taille de la queue (255 commandes) et le comportement du systeme une fois que cette queue est remplie (j'ai l'impression que le kernel attend qu'une entrée soit libérée pour stocker la suivante et passer en mode utilisateur).
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.
-- on passe la moitié de son temps à refaire ce que l'on n'a pas eu le temps de faire correctement. Loi de Myers.
Emmanuel Florac
Le Fri, 31 Oct 2003 11:46:17 +0100, Francois Petillon écrivait:
Quel est le FS utilisé?
ext2
Ah, et tu en es content? Il était systématiquement loin derrière dans tous mes tests...
Autre piste : en mettant deux cartes 3ware, tu peux striper les deux volumes logiques et adapter la granularité de ton bloc au niveau de LVM (ou de linux RAID).
Ç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 tenant aussi, pourquoi veux-tu qu'ils soient éclatés?
-- In girum imus nocte et consumimur igni.
Le Fri, 31 Oct 2003 11:46:17 +0100, Francois Petillon écrivait:
Quel est le FS utilisé?
ext2
Ah, et tu en es content? Il était systématiquement loin derrière dans
tous mes tests...
Autre piste : en mettant deux cartes 3ware, tu peux striper les deux
volumes logiques et adapter la granularité de ton bloc au niveau de LVM
(ou de linux RAID).
Ç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
tenant aussi, pourquoi veux-tu qu'ils soient éclatés?
Le Fri, 31 Oct 2003 11:46:17 +0100, Francois Petillon écrivait:
Quel est le FS utilisé?
ext2
Ah, et tu en es content? Il était systématiquement loin derrière dans tous mes tests...
Autre piste : en mettant deux cartes 3ware, tu peux striper les deux volumes logiques et adapter la granularité de ton bloc au niveau de LVM (ou de linux RAID).
Ç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 tenant aussi, pourquoi veux-tu qu'ils soient éclatés?
