je desire dupliquer un gros volume (un filesystem de plus de 300Go)
d'une machine a l'autre a travers le reseau. Connaissez vous des
methode plus rapide autre que tar over ssh ou scp ?
je desire dupliquer un gros volume (un filesystem de plus de 300Go) d'une machine a l'autre a travers le reseau. Connaissez vous des methode plus rapide autre que tar over ssh ou scp ?
Beaucoup de petits fichiers, peu de gros, ou moyennement de moyens ?
immo30@gmail.com wrote in message
<1158768462.564151.62480@i42g2000cwa.googlegroups.com>:
je desire dupliquer un gros volume (un filesystem de plus de 300Go)
d'une machine a l'autre a travers le reseau. Connaissez vous des
methode plus rapide autre que tar over ssh ou scp ?
Beaucoup de petits fichiers, peu de gros, ou moyennement de moyens ?
je desire dupliquer un gros volume (un filesystem de plus de 300Go) d'une machine a l'autre a travers le reseau. Connaissez vous des methode plus rapide autre que tar over ssh ou scp ?
Beaucoup de petits fichiers, peu de gros, ou moyennement de moyens ?
Pascal Bourguignon
Nicolas George <nicolas$ writes:
wrote in message :
je desire dupliquer un gros volume (un filesystem de plus de 300Go) d'une machine a l'autre a travers le reseau. Connaissez vous des methode plus rapide autre que tar over ssh ou scp ?
Beaucoup de petits fichiers, peu de gros, ou moyennement de moyens ?
Justement, tar/ssh est le plus rapide, si on a besoin de ssh.
Si les deux processeurs sont rapides, on peut compresser (gzip plutôt que bzip2) pour gagner sur la taille à transferer.
Si on est sur un réseau local on peut utiliser rsh à la place de ssh, pour gagner quelques pourcents. Sinon, configurer ssh pour ne pas compresser (et ne pas utiliser l'option -C), et laisser tar le faire.
Sinon, on ne fait pas mieux que:
tar -C $sourcedir -zcf - . | ssh $remotehost tar -C $destinationdir -zxf -
Se méfier de scp: il ne gère pas les liens symboliques (encore moins les liens durs). C'est à dire qu'en transfère deux copies!
ADVISORY: There is an extremely small but nonzero chance that, through a process known as "tunneling," this product may spontaneously disappear from its present location and reappear at any random place in the universe, including your neighbor's domicile. The manufacturer will not be responsible for any damages or inconveniences that may result.
Nicolas George <nicolas$george@salle-s.org> writes:
immo30@gmail.com wrote in message
<1158768462.564151.62480@i42g2000cwa.googlegroups.com>:
je desire dupliquer un gros volume (un filesystem de plus de 300Go)
d'une machine a l'autre a travers le reseau. Connaissez vous des
methode plus rapide autre que tar over ssh ou scp ?
Beaucoup de petits fichiers, peu de gros, ou moyennement de moyens ?
Justement, tar/ssh est le plus rapide, si on a besoin de ssh.
Si les deux processeurs sont rapides, on peut compresser (gzip plutôt
que bzip2) pour gagner sur la taille à transferer.
Si on est sur un réseau local on peut utiliser rsh à la place de ssh,
pour gagner quelques pourcents. Sinon, configurer ssh pour ne pas
compresser (et ne pas utiliser l'option -C), et laisser tar le faire.
Sinon, on ne fait pas mieux que:
tar -C $sourcedir -zcf - . | ssh $remotehost tar -C $destinationdir -zxf -
Se méfier de scp: il ne gère pas les liens symboliques (encore moins
les liens durs). C'est à dire qu'en transfère deux copies!
ADVISORY: There is an extremely small but nonzero chance that,
through a process known as "tunneling," this product may
spontaneously disappear from its present location and reappear at
any random place in the universe, including your neighbor's
domicile. The manufacturer will not be responsible for any damages
or inconveniences that may result.
je desire dupliquer un gros volume (un filesystem de plus de 300Go) d'une machine a l'autre a travers le reseau. Connaissez vous des methode plus rapide autre que tar over ssh ou scp ?
Beaucoup de petits fichiers, peu de gros, ou moyennement de moyens ?
Justement, tar/ssh est le plus rapide, si on a besoin de ssh.
Si les deux processeurs sont rapides, on peut compresser (gzip plutôt que bzip2) pour gagner sur la taille à transferer.
Si on est sur un réseau local on peut utiliser rsh à la place de ssh, pour gagner quelques pourcents. Sinon, configurer ssh pour ne pas compresser (et ne pas utiliser l'option -C), et laisser tar le faire.
Sinon, on ne fait pas mieux que:
tar -C $sourcedir -zcf - . | ssh $remotehost tar -C $destinationdir -zxf -
Se méfier de scp: il ne gère pas les liens symboliques (encore moins les liens durs). C'est à dire qu'en transfère deux copies!
ADVISORY: There is an extremely small but nonzero chance that, through a process known as "tunneling," this product may spontaneously disappear from its present location and reappear at any random place in the universe, including your neighbor's domicile. The manufacturer will not be responsible for any damages or inconveniences that may result.
Nicolas George
Pascal Bourguignon wrote in message :
Sinon, on ne fait pas mieux que:
tar -C $sourcedir -zcf - . | ssh $remotehost tar -C $destinationdir -zxf -
Ce n'est pas clair du tout. Si on a une myriade de tout petits fichiers, copier le filesystem lui-même plutôt que les fichiers par l'API Unix peut être plus efficace, parce que ça évite toutes les manipulations de méta-données pendant la copie.
Pascal Bourguignon wrote in message
<871wq69uom.fsf@thalassa.informatimago.com>:
Sinon, on ne fait pas mieux que:
tar -C $sourcedir -zcf - . | ssh $remotehost tar -C $destinationdir -zxf -
Ce n'est pas clair du tout. Si on a une myriade de tout petits fichiers,
copier le filesystem lui-même plutôt que les fichiers par l'API Unix peut
être plus efficace, parce que ça évite toutes les manipulations de
méta-données pendant la copie.
tar -C $sourcedir -zcf - . | ssh $remotehost tar -C $destinationdir -zxf -
Ce n'est pas clair du tout. Si on a une myriade de tout petits fichiers, copier le filesystem lui-même plutôt que les fichiers par l'API Unix peut être plus efficace, parce que ça évite toutes les manipulations de méta-données pendant la copie.
Pascal Bourguignon
Nicolas George <nicolas$ writes:
Pascal Bourguignon wrote in message :
Sinon, on ne fait pas mieux que:
tar -C $sourcedir -zcf - . | ssh $remotehost tar -C $destinationdir -zxf -
Ce n'est pas clair du tout. Si on a une myriade de tout petits fichiers, copier le filesystem lui-même plutôt que les fichiers par l'API Unix peut être plus efficace, parce que ça évite toutes les manipulations de méta-données pendant la copie.
Bien entendu, ça dépend si le file system est plein ou pas, et si les deux file system sont de la même taille (et si les deux systèmes sont les mêmes!). Autrement dit, le cas où ça peut être intéressant de faire un:
En général, la vitesse du réseau est suffisament plus lente que celle des disques durs pour que les tars ne soient pas à la traine en lisant et écrivant les metadonnées...
-- __Pascal Bourguignon__ http://www.informatimago.com/ Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we. -- Georges W. Bush
Nicolas George <nicolas$george@salle-s.org> writes:
Pascal Bourguignon wrote in message
<871wq69uom.fsf@thalassa.informatimago.com>:
Sinon, on ne fait pas mieux que:
tar -C $sourcedir -zcf - . | ssh $remotehost tar -C $destinationdir -zxf -
Ce n'est pas clair du tout. Si on a une myriade de tout petits fichiers,
copier le filesystem lui-même plutôt que les fichiers par l'API Unix peut
être plus efficace, parce que ça évite toutes les manipulations de
méta-données pendant la copie.
Bien entendu, ça dépend si le file system est plein ou pas, et si les
deux file system sont de la même taille (et si les deux systèmes sont
les mêmes!). Autrement dit, le cas où ça peut être intéressant de
faire un:
En général, la vitesse du réseau est suffisament plus lente que celle
des disques durs pour que les tars ne soient pas à la traine en lisant
et écrivant les metadonnées...
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
tar -C $sourcedir -zcf - . | ssh $remotehost tar -C $destinationdir -zxf -
Ce n'est pas clair du tout. Si on a une myriade de tout petits fichiers, copier le filesystem lui-même plutôt que les fichiers par l'API Unix peut être plus efficace, parce que ça évite toutes les manipulations de méta-données pendant la copie.
Bien entendu, ça dépend si le file system est plein ou pas, et si les deux file system sont de la même taille (et si les deux systèmes sont les mêmes!). Autrement dit, le cas où ça peut être intéressant de faire un:
En général, la vitesse du réseau est suffisament plus lente que celle des disques durs pour que les tars ne soient pas à la traine en lisant et écrivant les metadonnées...
-- __Pascal Bourguignon__ http://www.informatimago.com/ Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we. -- Georges W. Bush
Thomas Samson
Pascal Bourguignon writes:
Nicolas George <nicolas$ writes:
Pascal Bourguignon wrote in message :
Sinon, on ne fait pas mieux que:
tar -C $sourcedir -zcf - . | ssh $remotehost tar -C $destinationdir -zxf -
Ce n'est pas clair du tout. Si on a une myriade de tout petits fichiers, copier le filesystem lui-même plutôt que les fichiers par l'API Unix peut être plus efficace, parce que ça évite toutes les manipulations de méta-données pendant la copie.
Bien entendu, ça dépend si le file system est plein ou pas, et si les deux file system sont de la même taille (et si les deux systèmes sont les mêmes!). Autrement dit, le cas où ça peut être intéressant de faire un:
Il y a d'autres options 'intermediaires' entre dd ou tar ... comme dump et les divers equivalents.
Et bien sur, il faut aussi considerer le debit disponible ainsi que la puissance de chaque machine ... j'ai connu des endroits ou utiliser netcat et tar sans compression etait nettement plus rapide que ssh (certes, moins secure).
Aussi, si la liaison entre les deux machines n'est pas fiable (vu la quantite de donnees, les chances de coupures pendant le transfert augmentent), rsync ou un equivalent peut rendre de grands services, en permettant de reprendre facilement le transfert (en prenant en compte les changements).
D'ailleurs, en parlant de changement ... il est preferable de s'assurer que les donnees copiees soit coherentes. Et autant c'est tres souvent le cas sur des petits transferts, autant sur un gros transfert, il faut s'assurer que rien ne modifie les fichiers pendant l'operation.
-- Thomas Samson Hildebrant's Principle: If you don't know where you are going, any road will get you there.
Nicolas George <nicolas$george@salle-s.org> writes:
Pascal Bourguignon wrote in message
<871wq69uom.fsf@thalassa.informatimago.com>:
Sinon, on ne fait pas mieux que:
tar -C $sourcedir -zcf - . | ssh $remotehost tar -C $destinationdir -zxf -
Ce n'est pas clair du tout. Si on a une myriade de tout petits fichiers,
copier le filesystem lui-même plutôt que les fichiers par l'API Unix peut
être plus efficace, parce que ça évite toutes les manipulations de
méta-données pendant la copie.
Bien entendu, ça dépend si le file system est plein ou pas, et si les
deux file system sont de la même taille (et si les deux systèmes sont
les mêmes!). Autrement dit, le cas où ça peut être intéressant de
faire un:
Il y a d'autres options 'intermediaires' entre dd ou tar ... comme dump
et les divers equivalents.
Et bien sur, il faut aussi considerer le debit disponible ainsi que la
puissance de chaque machine ... j'ai connu des endroits ou utiliser
netcat et tar sans compression etait nettement plus rapide que ssh
(certes, moins secure).
Aussi, si la liaison entre les deux machines n'est pas fiable (vu la
quantite de donnees, les chances de coupures pendant le transfert
augmentent), rsync ou un equivalent peut rendre de grands services, en
permettant de reprendre facilement le transfert (en prenant en compte
les changements).
D'ailleurs, en parlant de changement ... il est preferable de s'assurer
que les donnees copiees soit coherentes. Et autant c'est tres souvent le
cas sur des petits transferts, autant sur un gros transfert, il faut
s'assurer que rien ne modifie les fichiers pendant l'operation.
--
Thomas Samson
Hildebrant's Principle:
If you don't know where you are going, any road will get you
there.
tar -C $sourcedir -zcf - . | ssh $remotehost tar -C $destinationdir -zxf -
Ce n'est pas clair du tout. Si on a une myriade de tout petits fichiers, copier le filesystem lui-même plutôt que les fichiers par l'API Unix peut être plus efficace, parce que ça évite toutes les manipulations de méta-données pendant la copie.
Bien entendu, ça dépend si le file system est plein ou pas, et si les deux file system sont de la même taille (et si les deux systèmes sont les mêmes!). Autrement dit, le cas où ça peut être intéressant de faire un:
Il y a d'autres options 'intermediaires' entre dd ou tar ... comme dump et les divers equivalents.
Et bien sur, il faut aussi considerer le debit disponible ainsi que la puissance de chaque machine ... j'ai connu des endroits ou utiliser netcat et tar sans compression etait nettement plus rapide que ssh (certes, moins secure).
Aussi, si la liaison entre les deux machines n'est pas fiable (vu la quantite de donnees, les chances de coupures pendant le transfert augmentent), rsync ou un equivalent peut rendre de grands services, en permettant de reprendre facilement le transfert (en prenant en compte les changements).
D'ailleurs, en parlant de changement ... il est preferable de s'assurer que les donnees copiees soit coherentes. Et autant c'est tres souvent le cas sur des petits transferts, autant sur un gros transfert, il faut s'assurer que rien ne modifie les fichiers pendant l'operation.
-- Thomas Samson Hildebrant's Principle: If you don't know where you are going, any road will get you there.
lhabert
Thomas Samson :
j'ai connu des endroits ou utiliser netcat et tar sans compression etait nettement plus rapide que ssh (certes, moins secure).
Tiens, j'ai souvenir de quelqu'un qui m'avait raconté avoir eu l'effet inverse, car netcat utilisait des buffers trop petits...
Thomas Samson :
j'ai connu des endroits ou utiliser netcat et tar sans compression etait
nettement plus rapide que ssh (certes, moins secure).
Tiens, j'ai souvenir de quelqu'un qui m'avait raconté avoir eu l'effet
inverse, car netcat utilisait des buffers trop petits...
j'ai connu des endroits ou utiliser netcat et tar sans compression etait nettement plus rapide que ssh (certes, moins secure).
Tiens, j'ai souvenir de quelqu'un qui m'avait raconté avoir eu l'effet inverse, car netcat utilisait des buffers trop petits...
manu
wrote:
je desire dupliquer un gros volume (un filesystem de plus de 300Go) d'une machine a l'autre a travers le reseau. Connaissez vous des methode plus rapide autre que tar over ssh ou scp ?
Si pas besoin de confidentialité, gzip et netcat gzip -9 < partition | nc destination port
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
<immo30@gmail.com> wrote:
je desire dupliquer un gros volume (un filesystem de plus de 300Go)
d'une machine a l'autre a travers le reseau. Connaissez vous des
methode plus rapide autre que tar over ssh ou scp ?
Si pas besoin de confidentialité, gzip et netcat
gzip -9 < partition | nc destination port
je desire dupliquer un gros volume (un filesystem de plus de 300Go) d'une machine a l'autre a travers le reseau. Connaissez vous des methode plus rapide autre que tar over ssh ou scp ?
Si pas besoin de confidentialité, gzip et netcat gzip -9 < partition | nc destination port
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
immo30
En fait, c'est des millions de petits fichiers, a transferer sur un meme filesystem de meme taille. Apres quelques discussions avec mon ami google, mon axe de recherche s'oriente vers une copie en mode raw...
Merci, momo
wrote in message :
je desire dupliquer un gros volume (un filesystem de plus de 300Go) d'une machine a l'autre a travers le reseau. Connaissez vous des methode plus rapide autre que tar over ssh ou scp ?
Beaucoup de petits fichiers, peu de gros, ou moyennement de moyens ?
En fait, c'est des millions de petits fichiers, a transferer sur un
meme filesystem de meme taille. Apres quelques discussions avec mon ami
google, mon axe de recherche s'oriente vers une copie en mode raw...
Merci,
momo
immo30@gmail.com wrote in message
<1158768462.564151.62480@i42g2000cwa.googlegroups.com>:
je desire dupliquer un gros volume (un filesystem de plus de 300Go)
d'une machine a l'autre a travers le reseau. Connaissez vous des
methode plus rapide autre que tar over ssh ou scp ?
Beaucoup de petits fichiers, peu de gros, ou moyennement de moyens ?
En fait, c'est des millions de petits fichiers, a transferer sur un meme filesystem de meme taille. Apres quelques discussions avec mon ami google, mon axe de recherche s'oriente vers une copie en mode raw...
Merci, momo
wrote in message :
je desire dupliquer un gros volume (un filesystem de plus de 300Go) d'une machine a l'autre a travers le reseau. Connaissez vous des methode plus rapide autre que tar over ssh ou scp ?
Beaucoup de petits fichiers, peu de gros, ou moyennement de moyens ?
Stephane Chazelas
On Wed, 20 Sep 2006 21:58:33 +0200, Pascal Bourguignon wrote:
Nicolas George <nicolas$ writes:
wrote in message :
je desire dupliquer un gros volume (un filesystem de plus de 300Go) d'une machine a l'autre a travers le reseau. Connaissez vous des methode plus rapide autre que tar over ssh ou scp ?
Beaucoup de petits fichiers, peu de gros, ou moyennement de moyens ?
Justement, tar/ssh est le plus rapide, si on a besoin de ssh.
Si les deux processeurs sont rapides, on peut compresser (gzip plutôt que bzip2) pour gagner sur la taille à transferer.
Si on est sur un réseau local on peut utiliser rsh à la place de ssh, pour gagner quelques pourcents. Sinon, configurer ssh pour ne pas compresser (et ne pas utiliser l'option -C), et laisser tar le faire.
Sinon, on ne fait pas mieux que:
tar -C $sourcedir -zcf - . | ssh $remotehost tar -C $destinationdir -zxf - [...]
Manque le "p" aux options de tar pour preserver les permissions ownerships.
($destinationdir ne doit pas contenir de caractere special au remote shell).
-- Stephane
On Wed, 20 Sep 2006 21:58:33 +0200, Pascal Bourguignon wrote:
Nicolas George <nicolas$george@salle-s.org> writes:
immo30@gmail.com wrote in message
<1158768462.564151.62480@i42g2000cwa.googlegroups.com>:
je desire dupliquer un gros volume (un filesystem de plus de 300Go)
d'une machine a l'autre a travers le reseau. Connaissez vous des
methode plus rapide autre que tar over ssh ou scp ?
Beaucoup de petits fichiers, peu de gros, ou moyennement de moyens ?
Justement, tar/ssh est le plus rapide, si on a besoin de ssh.
Si les deux processeurs sont rapides, on peut compresser (gzip plutôt
que bzip2) pour gagner sur la taille à transferer.
Si on est sur un réseau local on peut utiliser rsh à la place de ssh,
pour gagner quelques pourcents. Sinon, configurer ssh pour ne pas
compresser (et ne pas utiliser l'option -C), et laisser tar le faire.
Sinon, on ne fait pas mieux que:
tar -C $sourcedir -zcf - . | ssh $remotehost tar -C $destinationdir -zxf -
[...]
Manque le "p" aux options de tar pour preserver les permissions
ownerships.
On Wed, 20 Sep 2006 21:58:33 +0200, Pascal Bourguignon wrote:
Nicolas George <nicolas$ writes:
wrote in message :
je desire dupliquer un gros volume (un filesystem de plus de 300Go) d'une machine a l'autre a travers le reseau. Connaissez vous des methode plus rapide autre que tar over ssh ou scp ?
Beaucoup de petits fichiers, peu de gros, ou moyennement de moyens ?
Justement, tar/ssh est le plus rapide, si on a besoin de ssh.
Si les deux processeurs sont rapides, on peut compresser (gzip plutôt que bzip2) pour gagner sur la taille à transferer.
Si on est sur un réseau local on peut utiliser rsh à la place de ssh, pour gagner quelques pourcents. Sinon, configurer ssh pour ne pas compresser (et ne pas utiliser l'option -C), et laisser tar le faire.
Sinon, on ne fait pas mieux que:
tar -C $sourcedir -zcf - . | ssh $remotehost tar -C $destinationdir -zxf - [...]
Manque le "p" aux options de tar pour preserver les permissions ownerships.
($destinationdir ne doit pas contenir de caractere special au remote shell).
-- Stephane
fabrice-pas-despame.bacchella
On Thu, 21 Sep 2006 06:48:33 +0200, (Emmanuel Dreyfus) wrote:
wrote:
je desire dupliquer un gros volume (un filesystem de plus de 300Go) d'une machine a l'autre a travers le reseau. Connaissez vous des methode plus rapide autre que tar over ssh ou scp ?
Si pas besoin de confidentialité, gzip et netcat gzip -9 < partition | nc destination port
je desire dupliquer un gros volume (un filesystem de plus de 300Go)
d'une machine a l'autre a travers le reseau. Connaissez vous des
methode plus rapide autre que tar over ssh ou scp ?
Si pas besoin de confidentialité, gzip et netcat
gzip -9 < partition | nc destination port
On Thu, 21 Sep 2006 06:48:33 +0200, (Emmanuel Dreyfus) wrote:
wrote:
je desire dupliquer un gros volume (un filesystem de plus de 300Go) d'une machine a l'autre a travers le reseau. Connaissez vous des methode plus rapide autre que tar over ssh ou scp ?
Si pas besoin de confidentialité, gzip et netcat gzip -9 < partition | nc destination port
