bonjour,
je souhaiterai faire une copie de mon dd de 80go sur un autre
disque de la meme taille.
ils sont partionner exactement de la meme facon.
j ai "formater" mon disque B
dd if=/dev/zero of=/dev/ad2 count=2
et j ai essaye de copier la disque A vers le B
dd if=/dev/ad1 of=/dev/ad2
dd: /dev/ad1: Input/output error
209914+0 records in
209914+0 records out
107475968 bytes transferred in 65.549117 secs (1639625
bytes/sec)
dd if=/dev/ad1 of=/dev/null
dd: /dev/ad1: Input/output error
209914+0 records in
209914+0 records out
107475968 bytes transferred in 34.388560 secs (3125341
bytes/sec)
c est la premiere fois que j ai un message de ce type...
je me demande donc si il est trop tard pour faire un backup de
disque.
Concernant le fork Ten15/TenDRA, j'ai eu beau lire le post l'annonçant, je n'ai pas bien compris le pourquoi de la chose, mais bon...
Grosso modo, il y a un groupe qui veut un compilateur qui pisse du bath code, mais qui bosse beaucoup sur la représentation intermédiaire (le format ANDF), et un groupe qui veut un compilateur qui manipule une bath représentation intermédiaire, mais qui bosse beaucoup sur production du code final.
Le tout avec une odeur de tempête dans un bocal.
Un peu le problème de la poule et de l'oeuf.
Voilà.
Concernant le fork Ten15/TenDRA, j'ai eu beau lire le post l'annonçant,
je n'ai pas bien compris le pourquoi de la chose, mais bon...
Grosso modo, il y a un groupe qui veut un compilateur qui pisse du bath
code, mais qui bosse beaucoup sur la représentation intermédiaire (le
format ANDF), et un groupe qui veut un compilateur qui manipule une bath
représentation intermédiaire, mais qui bosse beaucoup sur production
du code final.
Concernant le fork Ten15/TenDRA, j'ai eu beau lire le post l'annonçant, je n'ai pas bien compris le pourquoi de la chose, mais bon...
Grosso modo, il y a un groupe qui veut un compilateur qui pisse du bath code, mais qui bosse beaucoup sur la représentation intermédiaire (le format ANDF), et un groupe qui veut un compilateur qui manipule une bath représentation intermédiaire, mais qui bosse beaucoup sur production du code final.
Le tout avec une odeur de tempête dans un bocal.
nicolas
On Mon, 13 Sep 2004 13:04:44 +0200, Jacques Caron wrote:
On 12 Sep 2004 01:16:32 -0700, Nico wrote:
merci bcp.
Le voici le voilà. Evidemment, penser à changer les devices dans les deux "open" vers le début sous peine de catastrophe. Le programme essaie de lire des gros blocs (pour aller plus vite), mais en cas de souci sur le gros bloc, il lit alors le gros bloc par petits bouts pour en récupérer le plus possible.
Tout ça sans garantie et à tes risques et périls, bien entendu. Bon courage!
int main(int argc,char **argv) { int i,n,in,out; unsigned char buf[1024*1024]; off_t off; time_t t,l; FILE *f;
t = time(0); in = open("/dev/rad1",O_RDONLY); out = open("/dev/rad3",O_WRONLY); f = fopen("errs","a"); off = 0; while (1) { l = time(0)-t; if (!l) l = 1; printf("Reading at offset %lld [large] %d secs %d MB/sn",off,l,off/(1024*1024)/l); lseek(in,off,SEEK_SET); n = read(in,buf,sizeof(buf)); if (n==-1) { for (i=0; i<2048;i++) { printf("Reading at offset %lld [small]n",off); lseek(in,off,SEEK_SET); n = read(in,buf,512); if (n == 0) break; if (n == -1) { fprintf(f,"Error at offset %lld block %lldn",off,off/512); fflush(f); off += 512; continue; } lseek(out,off,SEEK_SET); write(out,buf,512); off += 512; continue; } if (n==0) break; continue; } if (n==0) break; lseek(out,off,SEEK_SET); write(out,buf,n); off += n; } fclose(f);
return 0; }
merci bcp je vais tester ca au passage j avais jamais penser qu on pouvais ouvrir un dd aussi facilement ;P unix c'est bien:)
-- Nicolas Cormier
On Mon, 13 Sep 2004 13:04:44 +0200, Jacques Caron wrote:
On 12 Sep 2004 01:16:32 -0700, Nico <n.cormier@gmail.com> wrote:
merci bcp.
Le voici le voilà. Evidemment, penser à changer les devices dans les
deux "open" vers le début sous peine de catastrophe. Le programme
essaie de lire des gros blocs (pour aller plus vite), mais en cas de
souci sur le gros bloc, il lit alors le gros bloc par petits bouts pour
en récupérer le plus possible.
Tout ça sans garantie et à tes risques et périls, bien entendu. Bon
courage!
int main(int argc,char **argv)
{
int i,n,in,out;
unsigned char buf[1024*1024];
off_t off;
time_t t,l;
FILE *f;
t = time(0);
in = open("/dev/rad1",O_RDONLY);
out = open("/dev/rad3",O_WRONLY);
f = fopen("errs","a");
off = 0;
while (1)
{
l = time(0)-t;
if (!l)
l = 1;
printf("Reading at offset %lld [large] %d secs %d
MB/sn",off,l,off/(1024*1024)/l);
lseek(in,off,SEEK_SET);
n = read(in,buf,sizeof(buf));
if (n==-1)
{
for (i=0; i<2048;i++)
{
printf("Reading at offset %lld [small]n",off);
lseek(in,off,SEEK_SET);
n = read(in,buf,512);
if (n == 0)
break;
if (n == -1)
{
fprintf(f,"Error at offset %lld block
%lldn",off,off/512);
fflush(f);
off += 512;
continue;
}
lseek(out,off,SEEK_SET);
write(out,buf,512);
off += 512;
continue;
}
if (n==0)
break;
continue;
}
if (n==0)
break;
lseek(out,off,SEEK_SET);
write(out,buf,n);
off += n;
}
fclose(f);
return 0;
}
merci bcp je vais tester ca
au passage j avais jamais penser qu on pouvais ouvrir un
dd aussi facilement ;P unix c'est bien:)
On Mon, 13 Sep 2004 13:04:44 +0200, Jacques Caron wrote:
On 12 Sep 2004 01:16:32 -0700, Nico wrote:
merci bcp.
Le voici le voilà. Evidemment, penser à changer les devices dans les deux "open" vers le début sous peine de catastrophe. Le programme essaie de lire des gros blocs (pour aller plus vite), mais en cas de souci sur le gros bloc, il lit alors le gros bloc par petits bouts pour en récupérer le plus possible.
Tout ça sans garantie et à tes risques et périls, bien entendu. Bon courage!
int main(int argc,char **argv) { int i,n,in,out; unsigned char buf[1024*1024]; off_t off; time_t t,l; FILE *f;
t = time(0); in = open("/dev/rad1",O_RDONLY); out = open("/dev/rad3",O_WRONLY); f = fopen("errs","a"); off = 0; while (1) { l = time(0)-t; if (!l) l = 1; printf("Reading at offset %lld [large] %d secs %d MB/sn",off,l,off/(1024*1024)/l); lseek(in,off,SEEK_SET); n = read(in,buf,sizeof(buf)); if (n==-1) { for (i=0; i<2048;i++) { printf("Reading at offset %lld [small]n",off); lseek(in,off,SEEK_SET); n = read(in,buf,512); if (n == 0) break; if (n == -1) { fprintf(f,"Error at offset %lld block %lldn",off,off/512); fflush(f); off += 512; continue; } lseek(out,off,SEEK_SET); write(out,buf,512); off += 512; continue; } if (n==0) break; continue; } if (n==0) break; lseek(out,off,SEEK_SET); write(out,buf,n); off += n; } fclose(f);
return 0; }
merci bcp je vais tester ca au passage j avais jamais penser qu on pouvais ouvrir un dd aussi facilement ;P unix c'est bien:)
-- Nicolas Cormier
Olivier Tharan
* Thomas Pornin (Mon, 13 Sep 2004 07:35:27 +0000 (UTC)):
Sous FreeBSD 4.10, "tar" s'annonce comme étant un "GNU tar 1.13.25". Sous FreebSD-5.3(-BETA4), "tar" est un lien sur "bsdtar" (qui n'est pas "pax") et il y a un "gtar" à côté, qui est le "tar" GNU. Je subodore que s'il y a des questions de licence, c'est juste pour avoir un système _d'installation_ entièrement BSD ; un FreeBSD installé est de toutes façons truffé de produits GNU (par exemple, les pages de man sont produites avec groff, qui est GNU ; le compilateur C est gcc, tout aussi GNU ; etc...).
Il me semble que GNU tar n'est pas tout à fait compatible avec POSIX (surtout sur certaines options), d'où l'écriture de bsdtar.
Voir http://lists.freebsd.org/pipermail/freebsd-current/2004-April/025177.html pour les explications.
Voir aussi http://people.freebsd.org/~kientzle/libarchive/ pour les détails de libarchive et bsdtar.
Sous FreeBSD 4.10, "tar" s'annonce comme étant un "GNU tar 1.13.25".
Sous FreebSD-5.3(-BETA4), "tar" est un lien sur "bsdtar" (qui n'est pas
"pax") et il y a un "gtar" à côté, qui est le "tar" GNU. Je subodore que
s'il y a des questions de licence, c'est juste pour avoir un système
_d'installation_ entièrement BSD ; un FreeBSD installé est de toutes
façons truffé de produits GNU (par exemple, les pages de man sont
produites avec groff, qui est GNU ; le compilateur C est gcc, tout aussi
GNU ; etc...).
Il me semble que GNU tar n'est pas tout à fait compatible avec POSIX
(surtout sur certaines options), d'où l'écriture de bsdtar.
Voir
http://lists.freebsd.org/pipermail/freebsd-current/2004-April/025177.html
pour les explications.
Voir aussi http://people.freebsd.org/~kientzle/libarchive/ pour les
détails de libarchive et bsdtar.
* Thomas Pornin (Mon, 13 Sep 2004 07:35:27 +0000 (UTC)):
Sous FreeBSD 4.10, "tar" s'annonce comme étant un "GNU tar 1.13.25". Sous FreebSD-5.3(-BETA4), "tar" est un lien sur "bsdtar" (qui n'est pas "pax") et il y a un "gtar" à côté, qui est le "tar" GNU. Je subodore que s'il y a des questions de licence, c'est juste pour avoir un système _d'installation_ entièrement BSD ; un FreeBSD installé est de toutes façons truffé de produits GNU (par exemple, les pages de man sont produites avec groff, qui est GNU ; le compilateur C est gcc, tout aussi GNU ; etc...).
Il me semble que GNU tar n'est pas tout à fait compatible avec POSIX (surtout sur certaines options), d'où l'écriture de bsdtar.
Voir http://lists.freebsd.org/pipermail/freebsd-current/2004-April/025177.html pour les explications.
Voir aussi http://people.freebsd.org/~kientzle/libarchive/ pour les détails de libarchive et bsdtar.
-- olive
Nicolas Le Scouarnec
Sauf, que pour des questions de licence, sur les BSD, tar est en fait pax, à qui manque pas mal d'options de tar (-W pour la vérification, entre autres, comme si les bandes étaient devenues fiables d'un coup)
On m'avait aussi signalé que GnuTar, gérait mal les fichiers spéciaux sous FreeBSD, notamment les fichiers devices, qui sont codé sur 16 bits au lieu de 8 ou quelque chose du genre.
Et sous FreeBSD 5, j'ai un GnuTar comme tar par défaut: $which tar;tar --version /usr/bin/tar tar (GNU tar) 1.13.25
Mais pour des opérations assez bas niveau comme le backup ou la duplication de filesystems, "dump" est mieux. tar a pour avantage qu'on peut prendre une image d'un filesystem "live"
-modulo les sockets ingorés et les fichiers de log qui risquent d'être tronqués.
Dump n'a meme plus ces limites...
dump impose en pratique un passage en single-user, ce qui pour la sauvegadre nocturne d'un serveur en prod, est difficilement faisable.
Sur FreeBSD 5, dump déclenche un snapshot qui prend une image du systeme de fichier a un instant donné, et dump travaillera ensuite sur cette image, si on utilise l'option -L.
-- Nicolas Le Scouarnec
Sauf, que pour des questions de licence, sur les BSD, tar est en fait
pax, à qui manque pas mal d'options de tar (-W pour la vérification,
entre autres, comme si les bandes étaient devenues fiables d'un coup)
On m'avait aussi signalé que GnuTar, gérait mal les fichiers spéciaux
sous FreeBSD, notamment les fichiers devices, qui sont codé sur 16 bits
au lieu de 8 ou quelque chose du genre.
Et sous FreeBSD 5, j'ai un GnuTar comme tar par défaut:
$which tar;tar --version
/usr/bin/tar
tar (GNU tar) 1.13.25
Mais pour des opérations assez bas niveau comme le
backup ou la duplication de filesystems, "dump" est mieux.
tar a pour avantage qu'on peut prendre une image d'un filesystem "live"
-modulo les sockets ingorés et les fichiers de log qui risquent d'être
tronqués.
Dump n'a meme plus ces limites...
dump impose en pratique un passage en single-user, ce qui pour la
sauvegadre nocturne d'un serveur en prod, est difficilement faisable.
Sur FreeBSD 5, dump déclenche un snapshot qui prend une image du
systeme de fichier a un instant donné, et dump travaillera ensuite sur
cette image, si on utilise l'option -L.
Sauf, que pour des questions de licence, sur les BSD, tar est en fait pax, à qui manque pas mal d'options de tar (-W pour la vérification, entre autres, comme si les bandes étaient devenues fiables d'un coup)
On m'avait aussi signalé que GnuTar, gérait mal les fichiers spéciaux sous FreeBSD, notamment les fichiers devices, qui sont codé sur 16 bits au lieu de 8 ou quelque chose du genre.
Et sous FreeBSD 5, j'ai un GnuTar comme tar par défaut: $which tar;tar --version /usr/bin/tar tar (GNU tar) 1.13.25
Mais pour des opérations assez bas niveau comme le backup ou la duplication de filesystems, "dump" est mieux. tar a pour avantage qu'on peut prendre une image d'un filesystem "live"
-modulo les sockets ingorés et les fichiers de log qui risquent d'être tronqués.
Dump n'a meme plus ces limites...
dump impose en pratique un passage en single-user, ce qui pour la sauvegadre nocturne d'un serveur en prod, est difficilement faisable.
Sur FreeBSD 5, dump déclenche un snapshot qui prend une image du systeme de fichier a un instant donné, et dump travaillera ensuite sur cette image, si on utilise l'option -L.
