sur un FreeBSD 5.4, PIV 3GHz, avec 2 disques SATA (carte mère supermicro
chip SATA Intel 6300ESB), je cherche à dupliquer mon disque de boot sur
un second disque. A titre d'expérience j'ai utilisé dd :
pour ceux que la question d'origine interesse, les réponses sur la ML valent le coup d'être lues.
patpro
talon
patpro ~ Patrick Proniewski wrote:
Salut,
pour ceux que la question d'origine interesse, les réponses sur la ML valent le coup d'être lues.
Mais encore, tu as réussi à te faire une opinion plus précise? Nombre de ces discussions ont tourné en eau de boudin, des benchs annoncés qui ne viennent jamais, etc. on a l'impression que tout le monde s'en fout.
patpro
--
Michel TALON
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
Salut,
pour ceux que la question d'origine interesse, les réponses sur la ML
freebsd-performance@freebsd.org valent le coup d'être lues.
Mais encore, tu as réussi à te faire une opinion plus précise?
Nombre de ces discussions ont tourné en eau de boudin, des benchs annoncés qui
ne viennent jamais, etc. on a l'impression que tout le monde s'en fout.
pour ceux que la question d'origine interesse, les réponses sur la ML valent le coup d'être lues.
Mais encore, tu as réussi à te faire une opinion plus précise? Nombre de ces discussions ont tourné en eau de boudin, des benchs annoncés qui ne viennent jamais, etc. on a l'impression que tout le monde s'en fout.
patpro
--
Michel TALON
patpro ~ Patrick Proniewski
In article <di0033$j2c$, (Michel Talon) wrote:
patpro ~ Patrick Proniewski wrote:
Salut,
pour ceux que la question d'origine interesse, les réponses sur la ML valent le coup d'être lues.
Mais encore, tu as réussi à te faire une opinion plus précise? Nombre de ces discussions ont tourné en eau de boudin, des benchs annoncés qui ne viennent jamais, etc. on a l'impression que tout le monde s'en fout.
je n'ai pas eu le temps de faire les tests supplémentaires que je veux faire (changer la taille des blocs, tester les deux disques indépendamment). Mais les explications sur les fonctionnements des IO (par exemple) m'ont éclairé sur divers aspects de la chose qui m'étaient inconnus (j'ai une formation de chimiste, pas d'informaticien).
patpro
In article <di0033$j2c$1@asmodee.lpthe.jussieu.fr>,
talon@lpthe.jussieu.fr (Michel Talon) wrote:
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
Salut,
pour ceux que la question d'origine interesse, les réponses sur la ML
freebsd-performance@freebsd.org valent le coup d'être lues.
Mais encore, tu as réussi à te faire une opinion plus précise?
Nombre de ces discussions ont tourné en eau de boudin, des benchs annoncés qui
ne viennent jamais, etc. on a l'impression que tout le monde s'en fout.
je n'ai pas eu le temps de faire les tests supplémentaires que je veux
faire (changer la taille des blocs, tester les deux disques
indépendamment). Mais les explications sur les fonctionnements des IO
(par exemple) m'ont éclairé sur divers aspects de la chose qui m'étaient
inconnus (j'ai une formation de chimiste, pas d'informaticien).
pour ceux que la question d'origine interesse, les réponses sur la ML valent le coup d'être lues.
Mais encore, tu as réussi à te faire une opinion plus précise? Nombre de ces discussions ont tourné en eau de boudin, des benchs annoncés qui ne viennent jamais, etc. on a l'impression que tout le monde s'en fout.
je n'ai pas eu le temps de faire les tests supplémentaires que je veux faire (changer la taille des blocs, tester les deux disques indépendamment). Mais les explications sur les fonctionnements des IO (par exemple) m'ont éclairé sur divers aspects de la chose qui m'étaient inconnus (j'ai une formation de chimiste, pas d'informaticien).
patpro
Marwan Burelle
In article <dhrj6d$78e$, Michel Talon wrote:
Dans le sens que dd et dump/restore utilisent évidemment les mêmes mécanismes noyau pour faire leur job, et donc que passer de l'un à l'autre ne sera qu'un emplâtre sur une jambe de bois pour résoudre le problème.
Mouais ... ça ne rend pas ma réponse mauvaise. La question était de savoir si utiliser dd était la bonne solution. Répondre que dump/restore est mieux (même si il y a des problèmes plus profond question perfs) est tout à fait justifiée, il suffit de comparer. Après il y a même probablement de bonnes raisons à cela.
Deuxièmement dans le sens que la passage à des dispositifs SCSI ne résoudra pas plus le problème, vu que je t'ai dans le thread cité un exemple d'un disque zip sur un contrôleur SCSI. Au contraire avec SCSI ce sera encore pire qu'avec ATA vu que toute la couche SCSI est sous le "Giant lock" à moins qu'il y ait eu des progrés récemment.
Quand je comparais le SCSI au ATA/SATA, c'était d'une manière général, je ne suis pas très au fait des évolutions de SATA, mais lorsque l'on fait du transfert disque à disque, le SCSI (tant que l'on reste sur le même controleur) reste plus performant, simplement parce qu'il n'interfère pas avec la mémoire et le processeur (donc moins d'interruptions et de cycles bouffés pour rien ... )
Ce n'est pas lié au système, c'est lié à l'architecture matérielle.
Tiens, voici une copie du message que j'ai vu sur Dragonfly: 300MHz, 288MB RAM with intel pro gigabit NIC: Debian Sarge 2.4: 355Mb/s with 200KB window size. FreeBSD 6.0-BETA5: 150Mb/s with 200KB window size. 250Mb/s with polling enabled. FreeBSD 4.11: 300Mb/s with default window size. 323Mb/s with 200KB window size. DragonFlyBSD snapshot: didnt support NIC. OpenBSD 3.7: 128Mb/s with default. 135Mb/s with a 200KB window size 2003 server: 405Mb/s with 200KB Window size. 188Mb/s with default settings.
Tu comprends quand on voit 2003 server: 405Mb/s <--> FreeBSD 6.0-BETA5: 250Mb/s il y a quelque chose qui commence à merder profondément. Se rapprocher des performances d'OpenBSD, ce n'est pas un exploit qui va faire entrer FreeBSD dans l'histoire.
Surement, maintenant, ce bench en particulière est un peu léger pour juger. J'ai une Intel pro gigabit dans ma machine actuellement, et par expérience je peux te dire que le driver est pourri, c'est déjà suffisant pour avoir des perfs de merde (ceux qui ont fait des tests de perfs avec des 3com sous linux doivent le savoir, sans trifouiller je ne sais plus où, la carte restait en halfduplex quoi qu'il arrive ... ) Pour le coup, je sais que le driver avait du mal a établir le mode de transfert de la carte (c'était même décrit dans la page de man) et les perfs que tu montres ressemble à des perfs en halfduplex face à des perfs en full ...
C'est bien beau de critiquer sur des détails, mais il y a surement plein d'autre facteurs en jeux et plein d'autres détails qui pourraient servir à justifier des assertions contraires aux tiennes. Tout ça ne fait pas avancer le débat.
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <dhrj6d$78e$1@asmodee.lpthe.jussieu.fr>, Michel Talon wrote:
Dans le sens que dd et dump/restore utilisent évidemment les mêmes mécanismes
noyau pour faire leur job, et donc que passer de l'un à l'autre ne sera qu'un
emplâtre sur une jambe de bois pour résoudre le problème.
Mouais ... ça ne rend pas ma réponse mauvaise. La question était de
savoir si utiliser dd était la bonne solution. Répondre que
dump/restore est mieux (même si il y a des problèmes plus profond
question perfs) est tout à fait justifiée, il suffit de
comparer. Après il y a même probablement de bonnes raisons à cela.
Deuxièmement dans le sens que la passage à des dispositifs SCSI ne résoudra
pas plus le problème, vu que je t'ai dans le thread cité un exemple d'un
disque zip sur un contrôleur SCSI. Au contraire avec SCSI ce sera encore pire
qu'avec ATA vu que toute la couche SCSI est sous le "Giant lock" à moins qu'il
y ait eu des progrés récemment.
Quand je comparais le SCSI au ATA/SATA, c'était d'une manière général,
je ne suis pas très au fait des évolutions de SATA, mais lorsque l'on
fait du transfert disque à disque, le SCSI (tant que l'on reste sur le
même controleur) reste plus performant, simplement parce qu'il
n'interfère pas avec la mémoire et le processeur (donc moins
d'interruptions et de cycles bouffés pour rien ... )
Ce n'est pas lié au système, c'est lié à l'architecture matérielle.
Tiens, voici une copie du message que j'ai vu sur Dragonfly:
300MHz, 288MB RAM with intel pro gigabit NIC:
Debian Sarge 2.4: 355Mb/s with 200KB window size.
FreeBSD 6.0-BETA5: 150Mb/s with 200KB window size. 250Mb/s with polling
enabled.
FreeBSD 4.11: 300Mb/s with default window size. 323Mb/s with 200KB window
size.
DragonFlyBSD snapshot: didnt support NIC.
OpenBSD 3.7: 128Mb/s with default. 135Mb/s with a 200KB window size
2003 server: 405Mb/s with 200KB Window size. 188Mb/s with default settings.
Tu comprends quand on voit 2003 server: 405Mb/s <--> FreeBSD
6.0-BETA5: 250Mb/s il y a quelque chose qui commence à merder
profondément. Se rapprocher des performances d'OpenBSD, ce n'est pas
un exploit qui va faire entrer FreeBSD dans l'histoire.
Surement, maintenant, ce bench en particulière est un peu léger pour
juger. J'ai une Intel pro gigabit dans ma machine actuellement, et par
expérience je peux te dire que le driver est pourri, c'est déjà
suffisant pour avoir des perfs de merde (ceux qui ont fait des tests
de perfs avec des 3com sous linux doivent le savoir, sans trifouiller
je ne sais plus où, la carte restait en halfduplex quoi qu'il arrive
... ) Pour le coup, je sais que le driver avait du mal a établir le
mode de transfert de la carte (c'était même décrit dans la page de
man) et les perfs que tu montres ressemble à des perfs en halfduplex
face à des perfs en full ...
C'est bien beau de critiquer sur des détails, mais il y a surement
plein d'autre facteurs en jeux et plein d'autres détails qui
pourraient servir à justifier des assertions contraires aux
tiennes. Tout ça ne fait pas avancer le débat.
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
Dans le sens que dd et dump/restore utilisent évidemment les mêmes mécanismes noyau pour faire leur job, et donc que passer de l'un à l'autre ne sera qu'un emplâtre sur une jambe de bois pour résoudre le problème.
Mouais ... ça ne rend pas ma réponse mauvaise. La question était de savoir si utiliser dd était la bonne solution. Répondre que dump/restore est mieux (même si il y a des problèmes plus profond question perfs) est tout à fait justifiée, il suffit de comparer. Après il y a même probablement de bonnes raisons à cela.
Deuxièmement dans le sens que la passage à des dispositifs SCSI ne résoudra pas plus le problème, vu que je t'ai dans le thread cité un exemple d'un disque zip sur un contrôleur SCSI. Au contraire avec SCSI ce sera encore pire qu'avec ATA vu que toute la couche SCSI est sous le "Giant lock" à moins qu'il y ait eu des progrés récemment.
Quand je comparais le SCSI au ATA/SATA, c'était d'une manière général, je ne suis pas très au fait des évolutions de SATA, mais lorsque l'on fait du transfert disque à disque, le SCSI (tant que l'on reste sur le même controleur) reste plus performant, simplement parce qu'il n'interfère pas avec la mémoire et le processeur (donc moins d'interruptions et de cycles bouffés pour rien ... )
Ce n'est pas lié au système, c'est lié à l'architecture matérielle.
Tiens, voici une copie du message que j'ai vu sur Dragonfly: 300MHz, 288MB RAM with intel pro gigabit NIC: Debian Sarge 2.4: 355Mb/s with 200KB window size. FreeBSD 6.0-BETA5: 150Mb/s with 200KB window size. 250Mb/s with polling enabled. FreeBSD 4.11: 300Mb/s with default window size. 323Mb/s with 200KB window size. DragonFlyBSD snapshot: didnt support NIC. OpenBSD 3.7: 128Mb/s with default. 135Mb/s with a 200KB window size 2003 server: 405Mb/s with 200KB Window size. 188Mb/s with default settings.
Tu comprends quand on voit 2003 server: 405Mb/s <--> FreeBSD 6.0-BETA5: 250Mb/s il y a quelque chose qui commence à merder profondément. Se rapprocher des performances d'OpenBSD, ce n'est pas un exploit qui va faire entrer FreeBSD dans l'histoire.
Surement, maintenant, ce bench en particulière est un peu léger pour juger. J'ai une Intel pro gigabit dans ma machine actuellement, et par expérience je peux te dire que le driver est pourri, c'est déjà suffisant pour avoir des perfs de merde (ceux qui ont fait des tests de perfs avec des 3com sous linux doivent le savoir, sans trifouiller je ne sais plus où, la carte restait en halfduplex quoi qu'il arrive ... ) Pour le coup, je sais que le driver avait du mal a établir le mode de transfert de la carte (c'était même décrit dans la page de man) et les perfs que tu montres ressemble à des perfs en halfduplex face à des perfs en full ...
C'est bien beau de critiquer sur des détails, mais il y a surement plein d'autre facteurs en jeux et plein d'autres détails qui pourraient servir à justifier des assertions contraires aux tiennes. Tout ça ne fait pas avancer le débat.
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
F. Senault
question subsidiaire, est ce que dd est une méthode pas trop stupide de faire cette duplication de disque ? :)
Pour savoir d'où vient l'éventuel étranglement, tu peux peut-être commencer par tester chaque disque avec un programme de bench fait pour, par exemple bonnie++. S'il y a un problème de driver ou de matériel, tu devrais avoir les mêmes genre de résultats.
Fred -- Today is a good day. Not because anything wonderful is happening, so much, but because my definition of a 'bad day' has been revised. (Chris Klein in the SDM)
question subsidiaire, est ce que dd est une méthode pas trop stupide de
faire cette duplication de disque ? :)
Pour savoir d'où vient l'éventuel étranglement, tu peux peut-être
commencer par tester chaque disque avec un programme de bench fait pour,
par exemple bonnie++. S'il y a un problème de driver ou de matériel, tu
devrais avoir les mêmes genre de résultats.
Fred
--
Today is a good day. Not because anything wonderful is happening, so
much, but because my definition of a 'bad day' has been revised.
(Chris Klein in the SDM)
question subsidiaire, est ce que dd est une méthode pas trop stupide de faire cette duplication de disque ? :)
Pour savoir d'où vient l'éventuel étranglement, tu peux peut-être commencer par tester chaque disque avec un programme de bench fait pour, par exemple bonnie++. S'il y a un problème de driver ou de matériel, tu devrais avoir les mêmes genre de résultats.
Fred -- Today is a good day. Not because anything wonderful is happening, so much, but because my definition of a 'bad day' has been revised. (Chris Klein in the SDM)
Alex Marandon
On 2005-10-05, patpro ~ Patrick Proniewski wrote:
je n'ai pas eu le temps de faire les tests supplémentaires
Quand on veux on peut.
(j'ai une formation de chimiste, pas d'informaticien).
La bonne excuse.
On 2005-10-05, patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
je n'ai pas eu le temps de faire les tests supplémentaires
Quand on veux on peut.
(j'ai une formation de chimiste, pas d'informaticien).
