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 :
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 :
# dd if=/dev/ad4 of=/dev/ad6 bs=1m
J'obtiens des perf que je trouve décevantes :
Tu enfonces une porte ouverte, tu as des myriades de messages: "les performances de dd sont minables" sur les mailing lists. Idem pour les performances des cartes réseau Gigabits. Il faut s'y faire FreeBSD-5 ou 6 se comportent trés mal dans cet exercice et pourtant se comportent globalement bien. Tu sais le dernier message que je viens de voir sur dragonfly, fait état d'une performance moindre de moitié pour le débit d'une carte Intel Gigabits sur FreeBSD-6 par rapport à Linux ou FreeBSD-4, mais ce qui est pire eux mêmes sont complètement largués par Windows Server 2003. Est-ce que tu crois rééllement que les performances sur des problèmes rééls sont comme ça?
--
Michel TALON
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
Bonjour,
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 :
# dd if=/dev/ad4 of=/dev/ad6 bs=1m
J'obtiens des perf que je trouve décevantes :
Tu enfonces une porte ouverte, tu as des myriades de messages:
"les performances de dd sont minables" sur les mailing lists. Idem
pour les performances des cartes réseau Gigabits. Il faut s'y faire
FreeBSD-5 ou 6 se comportent trés mal dans cet exercice et pourtant
se comportent globalement bien. Tu sais le dernier message que je viens de voir
sur dragonfly, fait état d'une performance moindre de moitié pour le débit
d'une carte Intel Gigabits sur FreeBSD-6 par rapport à Linux ou FreeBSD-4,
mais ce qui est pire eux mêmes sont complètement largués par Windows
Server 2003. Est-ce que tu crois rééllement que les performances sur des
problèmes rééls sont comme ça?
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 :
# dd if=/dev/ad4 of=/dev/ad6 bs=1m
J'obtiens des perf que je trouve décevantes :
Tu enfonces une porte ouverte, tu as des myriades de messages: "les performances de dd sont minables" sur les mailing lists. Idem pour les performances des cartes réseau Gigabits. Il faut s'y faire FreeBSD-5 ou 6 se comportent trés mal dans cet exercice et pourtant se comportent globalement bien. Tu sais le dernier message que je viens de voir sur dragonfly, fait état d'une performance moindre de moitié pour le débit d'une carte Intel Gigabits sur FreeBSD-6 par rapport à Linux ou FreeBSD-4, mais ce qui est pire eux mêmes sont complètement largués par Windows Server 2003. Est-ce que tu crois rééllement que les performances sur des problèmes rééls sont comme ça?
--
Michel TALON
patpro ~ patrick proniewski
In article <dhout9$1ei2$, (Michel Talon) wrote:
patpro ~ patrick proniewski wrote:
Bonjour,
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 :
# dd if=/dev/ad4 of=/dev/ad6 bs=1m
J'obtiens des perf que je trouve décevantes :
Tu enfonces une porte ouverte, tu as des myriades de messages: "les performances de dd sont minables" sur les mailing lists.
ben les perf de dd c'est pas tres grave, j'ai meme pas pensé que ça pouvait venir de lui en fait.
Est-ce que tu crois rééllement que les performances sur des problèmes rééls sont comme ça?
pas vraiment, la question pour moi c'était surtout : est ce que j'ai raté un truc par exemple dans le BIOS, dans mon formatage, est ce que mon install FreeBSD est complétement à la ramasse, est ce que j'ai des perf minables parce que j'ai pas les bons param sysctl... ce genre d'angoisse existentielle qui me prend avant de mettre une machine en prod à 3h de trajet de chez moi :) Je suis passé brutalement de 4.10 à 5.4, en changeant radicalement de matos au passage, et je voudrais bien vérifier que je ne sous exploite pas trop le nouvel OS et le nouveau matériel par manque d'attention.
voila le but de ma question :)
patpro
In article <dhout9$1ei2$1@asmodee.lpthe.jussieu.fr>,
talon@lpthe.jussieu.fr (Michel Talon) wrote:
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
Bonjour,
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 :
# dd if=/dev/ad4 of=/dev/ad6 bs=1m
J'obtiens des perf que je trouve décevantes :
Tu enfonces une porte ouverte, tu as des myriades de messages:
"les performances de dd sont minables" sur les mailing lists.
ben les perf de dd c'est pas tres grave, j'ai meme pas pensé que ça
pouvait venir de lui en fait.
Est-ce que tu crois rééllement que les performances sur des
problèmes rééls sont comme ça?
pas vraiment, la question pour moi c'était surtout : est ce que j'ai
raté un truc par exemple dans le BIOS, dans mon formatage, est ce que
mon install FreeBSD est complétement à la ramasse, est ce que j'ai des
perf minables parce que j'ai pas les bons param sysctl... ce genre
d'angoisse existentielle qui me prend avant de mettre une machine en
prod à 3h de trajet de chez moi :)
Je suis passé brutalement de 4.10 à 5.4, en changeant radicalement de
matos au passage, et je voudrais bien vérifier que je ne sous exploite
pas trop le nouvel OS et le nouveau matériel par manque d'attention.
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 :
# dd if=/dev/ad4 of=/dev/ad6 bs=1m
J'obtiens des perf que je trouve décevantes :
Tu enfonces une porte ouverte, tu as des myriades de messages: "les performances de dd sont minables" sur les mailing lists.
ben les perf de dd c'est pas tres grave, j'ai meme pas pensé que ça pouvait venir de lui en fait.
Est-ce que tu crois rééllement que les performances sur des problèmes rééls sont comme ça?
pas vraiment, la question pour moi c'était surtout : est ce que j'ai raté un truc par exemple dans le BIOS, dans mon formatage, est ce que mon install FreeBSD est complétement à la ramasse, est ce que j'ai des perf minables parce que j'ai pas les bons param sysctl... ce genre d'angoisse existentielle qui me prend avant de mettre une machine en prod à 3h de trajet de chez moi :) Je suis passé brutalement de 4.10 à 5.4, en changeant radicalement de matos au passage, et je voudrais bien vérifier que je ne sous exploite pas trop le nouvel OS et le nouveau matériel par manque d'attention.
voila le but de ma question :)
patpro
talon
patpro ~ patrick proniewski wrote:
ben les perf de dd c'est pas tres grave, j'ai meme pas pensé que ça pouvait venir de lui en fait.
Non ce n'est pas dd en lui même qui est en cause, c'est le système qui se noie sous les interruptions, les verrous, etc. Il te suffit de chercher à écrire un gros fichier sur une partition DOS et de regarder systat -vmstat en même temps pour vérifier l'horreur de ce qui se passe, et bien entendu tu n'en croiras même pas ta montre du temps que ça prend. Chez moi j'ai un ZIP avec une partition DOS monté sur un contrôleur SCSI. Là c'est la totale, il faut compter une heure pour remplir les 100 mégas du zip (*). Bien entendu le grand architecte phk de GEOM, etc. s'en fout totalement. Pourtant je dois dire qu'en usage courant ma machine a l'air rapide.
(*) note qu'une écriture directe sur le zip "raw" avec dd n'est pas si lamentable à condition d'avoir un bs raisonnable genre 16k. On arrive à un débit meilleur que la moitié de la vitesse théorique du zip. Mais si on ajoute les écritures dans le système de fichiers msdos, alors on part sur la lune.
--
Michel TALON
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
ben les perf de dd c'est pas tres grave, j'ai meme pas pensé que ça
pouvait venir de lui en fait.
Non ce n'est pas dd en lui même qui est en cause, c'est le système qui se noie
sous les interruptions, les verrous, etc. Il te suffit de chercher à écrire un
gros fichier sur une partition DOS et de regarder systat -vmstat en même temps
pour vérifier l'horreur de ce qui se passe, et bien entendu tu n'en croiras
même pas ta montre du temps que ça prend. Chez moi j'ai un ZIP avec une
partition DOS monté sur un contrôleur SCSI. Là c'est la totale, il faut
compter une heure pour remplir les 100 mégas du zip (*). Bien entendu le grand
architecte phk de GEOM, etc. s'en fout totalement. Pourtant je dois dire qu'en
usage courant ma machine a l'air rapide.
(*) note qu'une écriture directe sur le zip "raw" avec dd n'est pas
si lamentable à condition d'avoir un bs raisonnable genre 16k. On arrive à un
débit meilleur que la moitié de la vitesse théorique du zip. Mais si on ajoute
les écritures dans le système de fichiers msdos, alors on part sur la lune.
ben les perf de dd c'est pas tres grave, j'ai meme pas pensé que ça pouvait venir de lui en fait.
Non ce n'est pas dd en lui même qui est en cause, c'est le système qui se noie sous les interruptions, les verrous, etc. Il te suffit de chercher à écrire un gros fichier sur une partition DOS et de regarder systat -vmstat en même temps pour vérifier l'horreur de ce qui se passe, et bien entendu tu n'en croiras même pas ta montre du temps que ça prend. Chez moi j'ai un ZIP avec une partition DOS monté sur un contrôleur SCSI. Là c'est la totale, il faut compter une heure pour remplir les 100 mégas du zip (*). Bien entendu le grand architecte phk de GEOM, etc. s'en fout totalement. Pourtant je dois dire qu'en usage courant ma machine a l'air rapide.
(*) note qu'une écriture directe sur le zip "raw" avec dd n'est pas si lamentable à condition d'avoir un bs raisonnable genre 16k. On arrive à un débit meilleur que la moitié de la vitesse théorique du zip. Mais si on ajoute les écritures dans le système de fichiers msdos, alors on part sur la lune.
--
Michel TALON
Marwan Burelle
In article , patpro ~ patrick proniewski wrote:
Bonjour,
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 :
# dd if=/dev/ad4 of=/dev/ad6 bs=1m
J'obtiens des perf que je trouve décevantes :
[snip]
est ce que je crois encore au pere noel ou est ce que ces perf sont vraiment en dessous de la normale ?
Bon, déjà dd n'est pas le bon outils ;)
Il y a un thread pas loin sur dump/restore et c'est vraiment le bon outil pour la réplication.
Ensuite, SATA ou pas SATA, tant que tu ne fais pas de SCSI, tu auras toujours un minimum de demande sur le processeur pour ce genre de chose (des interruptions et autres, les bus dérivés de l'ide requiert toujours un passage par le centre, il n'y a qu'en SCSI où les devices sont, presque, capable de se parler entre eux ... ) donc l'activité de la machine n'est pas négligeable ...
question subsidiaire, est ce que dd est une méthode pas trop stupide de faire cette duplication de disque ? :)
Déjà répondu, dump/restore sont tes amis ;)
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <patpro-FC23B6.16422602102005@news16-e.proxad.net>,
patpro ~ patrick proniewski wrote:
Bonjour,
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 :
# dd if=/dev/ad4 of=/dev/ad6 bs=1m
J'obtiens des perf que je trouve décevantes :
[snip]
est ce que je crois encore au pere noel ou est ce que ces perf sont
vraiment en dessous de la normale ?
Bon, déjà dd n'est pas le bon outils ;)
Il y a un thread pas loin sur dump/restore et c'est vraiment le bon
outil pour la réplication.
Ensuite, SATA ou pas SATA, tant que tu ne fais pas de SCSI, tu auras
toujours un minimum de demande sur le processeur pour ce genre de
chose (des interruptions et autres, les bus dérivés de l'ide requiert
toujours un passage par le centre, il n'y a qu'en SCSI où les devices
sont, presque, capable de se parler entre eux ... ) donc l'activité de
la machine n'est pas négligeable ...
question subsidiaire, est ce que dd est une méthode pas trop stupide de
faire cette duplication de disque ? :)
Déjà répondu, dump/restore sont tes amis ;)
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
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 :
# dd if=/dev/ad4 of=/dev/ad6 bs=1m
J'obtiens des perf que je trouve décevantes :
[snip]
est ce que je crois encore au pere noel ou est ce que ces perf sont vraiment en dessous de la normale ?
Bon, déjà dd n'est pas le bon outils ;)
Il y a un thread pas loin sur dump/restore et c'est vraiment le bon outil pour la réplication.
Ensuite, SATA ou pas SATA, tant que tu ne fais pas de SCSI, tu auras toujours un minimum de demande sur le processeur pour ce genre de chose (des interruptions et autres, les bus dérivés de l'ide requiert toujours un passage par le centre, il n'y a qu'en SCSI où les devices sont, presque, capable de se parler entre eux ... ) donc l'activité de la machine n'est pas négligeable ...
question subsidiaire, est ce que dd est une méthode pas trop stupide de faire cette duplication de disque ? :)
Déjà répondu, dump/restore sont tes amis ;)
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
patpro ~ Patrick Proniewski
In article , Marwan Burelle wrote:
Déjà répondu, dump/restore sont tes amis ;)
restore sait parler à un disque non formaté pour répliquer une table de partition, en incluant tout ce qu'il faut pour que ce soit bootable ?
Parce que bon, là ça marche ;) J'avais posté mon message initial avant que la manip de dd soit terminée, mais elle s'est bien finie, et le disque est bootable et identique à mon disque de départ.
patpro
In article <slrndk2a5l.14n7.burelle@pc5-179.lri.fr>,
Marwan Burelle <burelle@lri.fr> wrote:
Déjà répondu, dump/restore sont tes amis ;)
restore sait parler à un disque non formaté pour répliquer une table de
partition, en incluant tout ce qu'il faut pour que ce soit bootable ?
Parce que bon, là ça marche ;)
J'avais posté mon message initial avant que la manip de dd soit
terminée, mais elle s'est bien finie, et le disque est bootable et
identique à mon disque de départ.
restore sait parler à un disque non formaté pour répliquer une table de partition, en incluant tout ce qu'il faut pour que ce soit bootable ?
Parce que bon, là ça marche ;) J'avais posté mon message initial avant que la manip de dd soit terminée, mais elle s'est bien finie, et le disque est bootable et identique à mon disque de départ.
patpro
talon
Marwan Burelle wrote:
question subsidiaire, est ce que dd est une méthode pas trop stupide de faire cette duplication de disque ? :)
Déjà répondu, dump/restore sont tes amis ;)
Marwan je ne veux pas retourner le couteau dans la plaie mais ce que tu dis est incroyablement faux, venant d'un informaticien professionnel.
--
Michel TALON
Marwan Burelle <burelle@lri.fr> wrote:
question subsidiaire, est ce que dd est une méthode pas trop stupide de
faire cette duplication de disque ? :)
Déjà répondu, dump/restore sont tes amis ;)
Marwan je ne veux pas retourner le couteau dans la plaie mais ce que tu dis
est incroyablement faux, venant d'un informaticien professionnel.
question subsidiaire, est ce que dd est une méthode pas trop stupide de faire cette duplication de disque ? :)
Déjà répondu, dump/restore sont tes amis ;)
Marwan je ne veux pas retourner le couteau dans la plaie mais ce que tu dis est incroyablement faux, venant d'un informaticien professionnel.
--
Michel TALON
Marwan Burelle
In article <dhreio$650$, Michel Talon wrote:
Marwan je ne veux pas retourner le couteau dans la plaie mais ce que tu dis est incroyablement faux, venant d'un informaticien professionnel.
Dans quel sens ? dd est mieux que dump/restore ? ou dump/restore ne réponde pas à l'usage demandé ?
Globalement, s'il s'agit de copié un fs, ça devrait suffir, s'il faut copier le "disque" (c'est à dire tout ce qu'il y a sur le device du premier au dernier cylindre) alors effectivement c'est dd qu'il faut.
(pour les perfs de dump/restore vs dd, l'expérience me parle en ce qui me concerne et ça me suffit ... )
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <dhreio$650$1@asmodee.lpthe.jussieu.fr>, Michel Talon wrote:
Marwan je ne veux pas retourner le couteau dans la plaie mais ce que tu dis
est incroyablement faux, venant d'un informaticien professionnel.
Dans quel sens ? dd est mieux que dump/restore ? ou dump/restore ne
réponde pas à l'usage demandé ?
Globalement, s'il s'agit de copié un fs, ça devrait suffir, s'il faut
copier le "disque" (c'est à dire tout ce qu'il y a sur le device du
premier au dernier cylindre) alors effectivement c'est dd qu'il faut.
(pour les perfs de dump/restore vs dd, l'expérience me parle en ce qui
me concerne et ça me suffit ... )
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
Marwan je ne veux pas retourner le couteau dans la plaie mais ce que tu dis est incroyablement faux, venant d'un informaticien professionnel.
Dans quel sens ? dd est mieux que dump/restore ? ou dump/restore ne réponde pas à l'usage demandé ?
Globalement, s'il s'agit de copié un fs, ça devrait suffir, s'il faut copier le "disque" (c'est à dire tout ce qu'il y a sur le device du premier au dernier cylindre) alors effectivement c'est dd qu'il faut.
(pour les perfs de dump/restore vs dd, l'expérience me parle en ce qui me concerne et ça me suffit ... )
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
talon
Marwan Burelle wrote:
In article <dhreio$650$, Michel Talon wrote:
Marwan je ne veux pas retourner le couteau dans la plaie mais ce que tu dis est incroyablement faux, venant d'un informaticien professionnel.
Dans quel sens ? dd est mieux que dump/restore ? ou dump/restore ne réponde pas à l'usage demandé ?
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.
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.
Globalement, s'il s'agit de copié un fs, ça devrait suffir, s'il faut copier le "disque" (c'est à dire tout ce qu'il y a sur le device du premier au dernier cylindre) alors effectivement c'est dd qu'il faut.
(pour les perfs de dump/restore vs dd, l'expérience me parle en ce qui me concerne et ça me suffit ... )
Tu peux gagner quelque chose avec dump/restore dans la mesure où il optimise un certain nombre de transfers, par exemple les fichiers "sparse" etc. Donc je veux bien croire que c'est plus rapide.
Le noeud de l'affaire c'est qu'il y a quelque chose d'absolument effroyablement mal performant dans le système des interruptions, verrous et autres, on n'arrive à avoir des perfs sur les cartes réseau GigE que en mode polling, etc. Les programmes violemment multithreadés comme mysql ont des performances abominables sous FreeBSD, etc. Tout ça finit par faire désordre.
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.
--
Michel TALON
Marwan Burelle <burelle@lri.fr> wrote:
In article <dhreio$650$1@asmodee.lpthe.jussieu.fr>, Michel Talon wrote:
Marwan je ne veux pas retourner le couteau dans la plaie mais ce que tu dis
est incroyablement faux, venant d'un informaticien professionnel.
Dans quel sens ? dd est mieux que dump/restore ? ou dump/restore ne
réponde pas à l'usage demandé ?
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.
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.
Globalement, s'il s'agit de copié un fs, ça devrait suffir, s'il faut
copier le "disque" (c'est à dire tout ce qu'il y a sur le device du
premier au dernier cylindre) alors effectivement c'est dd qu'il faut.
(pour les perfs de dump/restore vs dd, l'expérience me parle en ce qui
me concerne et ça me suffit ... )
Tu peux gagner quelque chose avec dump/restore dans la mesure où il optimise
un certain nombre de transfers, par exemple les fichiers "sparse" etc. Donc
je veux bien croire que c'est plus rapide.
Le noeud de l'affaire c'est qu'il y a quelque chose d'absolument
effroyablement mal performant dans le système des interruptions, verrous et
autres, on n'arrive à avoir des perfs sur les cartes réseau GigE que en mode
polling, etc. Les programmes violemment multithreadés comme mysql ont des
performances abominables sous FreeBSD, etc. Tout ça finit par faire désordre.
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.
Marwan je ne veux pas retourner le couteau dans la plaie mais ce que tu dis est incroyablement faux, venant d'un informaticien professionnel.
Dans quel sens ? dd est mieux que dump/restore ? ou dump/restore ne réponde pas à l'usage demandé ?
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.
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.
Globalement, s'il s'agit de copié un fs, ça devrait suffir, s'il faut copier le "disque" (c'est à dire tout ce qu'il y a sur le device du premier au dernier cylindre) alors effectivement c'est dd qu'il faut.
(pour les perfs de dump/restore vs dd, l'expérience me parle en ce qui me concerne et ça me suffit ... )
Tu peux gagner quelque chose avec dump/restore dans la mesure où il optimise un certain nombre de transfers, par exemple les fichiers "sparse" etc. Donc je veux bien croire que c'est plus rapide.
Le noeud de l'affaire c'est qu'il y a quelque chose d'absolument effroyablement mal performant dans le système des interruptions, verrous et autres, on n'arrive à avoir des perfs sur les cartes réseau GigE que en mode polling, etc. Les programmes violemment multithreadés comme mysql ont des performances abominables sous FreeBSD, etc. Tout ça finit par faire désordre.
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.
--
Michel TALON
Miod Vallat
Dans quel sens ? dd est mieux que dump/restore ? ou dump/restore ne réponde pas à l'usage demandé ?
Dump et restore ne parlent que l'UFS. Donc pour le Zip avec un système de fichiers FAT, tu repasseras.
Dans quel sens ? dd est mieux que dump/restore ? ou dump/restore ne
réponde pas à l'usage demandé ?
Dump et restore ne parlent que l'UFS. Donc pour le Zip avec un système
de fichiers FAT, tu repasseras.
Dans quel sens ? dd est mieux que dump/restore ? ou dump/restore ne réponde pas à l'usage demandé ?
Dump et restore ne parlent que l'UFS. Donc pour le Zip avec un système de fichiers FAT, tu repasseras.
Arnaud Launay
Le Mon, 3 Oct 2005 14:18:00 +0000 (UTC), Michel Talon écrivit:
Déjà répondu, dump/restore sont tes amis ;) Marwan je ne veux pas retourner le couteau dans la plaie mais
ce que tu dis est incroyablement faux, venant d'un informaticien professionnel.
C'est un chercheur professionnel, une espèce nuisible qu'il ne faut pas confondre avec les informaticiens professionnels, espèce nuisible aussi, mais dont les spécimens ont usuellement plus de 55 ans.
Le Mon, 3 Oct 2005 14:18:00 +0000 (UTC), Michel Talon écrivit:
Déjà répondu, dump/restore sont tes amis ;)
Marwan je ne veux pas retourner le couteau dans la plaie mais
ce que tu dis est incroyablement faux, venant d'un
informaticien professionnel.
C'est un chercheur professionnel, une espèce nuisible qu'il ne
faut pas confondre avec les informaticiens professionnels,
espèce nuisible aussi, mais dont les spécimens ont usuellement
plus de 55 ans.
Le Mon, 3 Oct 2005 14:18:00 +0000 (UTC), Michel Talon écrivit:
Déjà répondu, dump/restore sont tes amis ;) Marwan je ne veux pas retourner le couteau dans la plaie mais
ce que tu dis est incroyablement faux, venant d'un informaticien professionnel.
C'est un chercheur professionnel, une espèce nuisible qu'il ne faut pas confondre avec les informaticiens professionnels, espèce nuisible aussi, mais dont les spécimens ont usuellement plus de 55 ans.
