bonjour a tous,
[...]
/dev/hdb1 480719056 343004368 113295488 76% /var/www
/dev/hdc1 480719056 343719196 112580660 76% /bkp/www
et le contenu semble le meme
ls -1a /var/www > ~/source.txt
ls -1a /bkp/www > ~/bkp.txt
diff ~/source.txt ~/bkp.txt ne me renvoie pas de difference
aucun autre process ne peut ecrire sur le dossier de destination. Auriez
vous une idée d'ou cela peut il venir?
bonjour a tous,
[...]
/dev/hdb1 480719056 343004368 113295488 76% /var/www
/dev/hdc1 480719056 343719196 112580660 76% /bkp/www
et le contenu semble le meme
ls -1a /var/www > ~/source.txt
ls -1a /bkp/www > ~/bkp.txt
diff ~/source.txt ~/bkp.txt ne me renvoie pas de difference
aucun autre process ne peut ecrire sur le dossier de destination. Auriez
vous une idée d'ou cela peut il venir?
bonjour a tous,
[...]
/dev/hdb1 480719056 343004368 113295488 76% /var/www
/dev/hdc1 480719056 343719196 112580660 76% /bkp/www
et le contenu semble le meme
ls -1a /var/www > ~/source.txt
ls -1a /bkp/www > ~/bkp.txt
diff ~/source.txt ~/bkp.txt ne me renvoie pas de difference
aucun autre process ne peut ecrire sur le dossier de destination. Auriez
vous une idée d'ou cela peut il venir?
Matthieu a écrit, lundi 20 mars 2006, à 08:28 :
> bonjour a tous,
bonjour,
Sinon, il peut y avoir des liens durs à la source, rsync ne les prése rve
pas sans l'option -H.
Matthieu a écrit, lundi 20 mars 2006, à 08:28 :
> bonjour a tous,
bonjour,
Sinon, il peut y avoir des liens durs à la source, rsync ne les prése rve
pas sans l'option -H.
Matthieu a écrit, lundi 20 mars 2006, à 08:28 :
> bonjour a tous,
bonjour,
Sinon, il peut y avoir des liens durs à la source, rsync ne les prése rve
pas sans l'option -H.
Le 20/03/06, Jacques L'helgoualc'h <lhh+ a écrit :
> Sinon, il peut y avoir des liens durs à la source, rsync ne les préserve
> pas sans l'option -H.
non il n'existe pas de liens que ce soit dans /var/www ou dans le dossier
servant de sauvegarde.
Le 20/03/06, Jacques L'helgoualc'h <lhh+no_spam@free.fr> a écrit :
> Sinon, il peut y avoir des liens durs à la source, rsync ne les préserve
> pas sans l'option -H.
non il n'existe pas de liens que ce soit dans /var/www ou dans le dossier
servant de sauvegarde.
Le 20/03/06, Jacques L'helgoualc'h <lhh+ a écrit :
> Sinon, il peut y avoir des liens durs à la source, rsync ne les préserve
> pas sans l'option -H.
non il n'existe pas de liens que ce soit dans /var/www ou dans le dossier
servant de sauvegarde.
rsync -raz --delete-after --stats /var/www 127.0.0.1::www/
rsync -raz --delete-after --stats /var/www 127.0.0.1::www/
rsync -raz --delete-after --stats /var/www 127.0.0.1::www/
Le lundi 20 mars 2006 à 08:28, d'après
Matthieu :
> rsync -raz --delete-after --stats /var/www 127.0.0.1::www/
Deux choses peuvent l'expliquer facilement : les "hard links" (-H pour
les préserver) et les "sparse files" (-S pour les gérer correctement) .
--
Thomas Parmelan
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Le lundi 20 mars 2006 à 08:28, d'après
Matthieu <ermelir@gmail.com> :
> rsync -raz --delete-after --stats /var/www 127.0.0.1::www/
Deux choses peuvent l'expliquer facilement : les "hard links" (-H pour
les préserver) et les "sparse files" (-S pour les gérer correctement) .
--
Thomas Parmelan
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
Le lundi 20 mars 2006 à 08:28, d'après
Matthieu :
> rsync -raz --delete-after --stats /var/www 127.0.0.1::www/
Deux choses peuvent l'expliquer facilement : les "hard links" (-H pour
les préserver) et les "sparse files" (-S pour les gérer correctement) .
--
Thomas Parmelan
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
bonjour a tous,
je realise une copie par rsync d'un dossier qui au final me fait du mirro ir
du dossier copié
les disques sont les memes, les systemes de fichier aussi (ext3).
seulement mon soucis c'est qu'une fois la synchronisation faite, la taille
du contenu, or je m'attendais a avoir strictement la meme chose vu la
commande:
rsync -raz --delete-after --stats /var/www 127.0.0.1::www/
bonjour a tous,
je realise une copie par rsync d'un dossier qui au final me fait du mirro ir
du dossier copié
les disques sont les memes, les systemes de fichier aussi (ext3).
seulement mon soucis c'est qu'une fois la synchronisation faite, la taille
du contenu, or je m'attendais a avoir strictement la meme chose vu la
commande:
rsync -raz --delete-after --stats /var/www 127.0.0.1::www/
bonjour a tous,
je realise une copie par rsync d'un dossier qui au final me fait du mirro ir
du dossier copié
les disques sont les memes, les systemes de fichier aussi (ext3).
seulement mon soucis c'est qu'une fois la synchronisation faite, la taille
du contenu, or je m'attendais a avoir strictement la meme chose vu la
commande:
rsync -raz --delete-after --stats /var/www 127.0.0.1::www/
/var/www/:
total 342971564
16 lost+found
/var/www/lost+found:
total 32
16 .
Le Lundi 20 Mars 2006 08:28, Matthieu a écrit:
> bonjour a tous,
>
> je realise une copie par rsync d'un dossier qui au final me fait du
mirroir
> du dossier copié
> les disques sont les memes, les systemes de fichier aussi (ext3).
> seulement mon soucis c'est qu'une fois la synchronisation faite, la
taille
> du contenu, or je m'attendais a avoir strictement la meme chose vu la
> commande:
>
> rsync -raz --delete-after --stats /var/www 127.0.0.1::www/
Est-on sur que l'option --delete-after implique l'option --delete ?
Moi, je mettrais bien --delete en plus.
[...]
PS: le "-r" est compris dans le "-a"
/var/www/:
total 342971564
16 lost+found
/var/www/lost+found:
total 32
16 .
Le Lundi 20 Mars 2006 08:28, Matthieu a écrit:
> bonjour a tous,
>
> je realise une copie par rsync d'un dossier qui au final me fait du
mirroir
> du dossier copié
> les disques sont les memes, les systemes de fichier aussi (ext3).
> seulement mon soucis c'est qu'une fois la synchronisation faite, la
taille
> du contenu, or je m'attendais a avoir strictement la meme chose vu la
> commande:
>
> rsync -raz --delete-after --stats /var/www 127.0.0.1::www/
Est-on sur que l'option --delete-after implique l'option --delete ?
Moi, je mettrais bien --delete en plus.
[...]
PS: le "-r" est compris dans le "-a"
/var/www/:
total 342971564
16 lost+found
/var/www/lost+found:
total 32
16 .
Le Lundi 20 Mars 2006 08:28, Matthieu a écrit:
> bonjour a tous,
>
> je realise une copie par rsync d'un dossier qui au final me fait du
mirroir
> du dossier copié
> les disques sont les memes, les systemes de fichier aussi (ext3).
> seulement mon soucis c'est qu'une fois la synchronisation faite, la
taille
> du contenu, or je m'attendais a avoir strictement la meme chose vu la
> commande:
>
> rsync -raz --delete-after --stats /var/www 127.0.0.1::www/
Est-on sur que l'option --delete-after implique l'option --delete ?
Moi, je mettrais bien --delete en plus.
[...]
PS: le "-r" est compris dans le "-a"
bonjour
non j'ai essayé aussi ces options, ca ne changeait rien.
La situation est revenue a la normale apres un redemarrage de la machine. Il
reste quand meme que sur un disque le dossier lost+found fait 4 octects, sur
l'autre 16
ls -1asR /bkp/www/ > ~/bkp.txt
ls -1asR /var/www/ > ~/var.txt
diff bkp.txt var.txt
1,2c1,2
< /bkp/www/:
< total 342971552
> /var/www/:
> total 342971564
505c505
< 4 lost+found
> 16 lost+found
507,509c507,509
< /bkp/www/lost+found:
< total 20
< 4 .
> /var/www/lost+found:
> total 32
> 16 .
je n'ai pas encore eu le temps d'analyser mes logs et si mes souvenirs sont
bons, sur un systeme unix, il n'existe pas de fragmentation concernant des
fichiers.
bref, je ne m'explique toujours pas pourquoi j'avais cette
difference de taille sur mes deux disques.
je vais analyser mes logs, mais si vous avez un éclair de genie, je veux
bien le partager :)
bonjour
non j'ai essayé aussi ces options, ca ne changeait rien.
La situation est revenue a la normale apres un redemarrage de la machine. Il
reste quand meme que sur un disque le dossier lost+found fait 4 octects, sur
l'autre 16
ls -1asR /bkp/www/ > ~/bkp.txt
ls -1asR /var/www/ > ~/var.txt
diff bkp.txt var.txt
1,2c1,2
< /bkp/www/:
< total 342971552
> /var/www/:
> total 342971564
505c505
< 4 lost+found
> 16 lost+found
507,509c507,509
< /bkp/www/lost+found:
< total 20
< 4 .
> /var/www/lost+found:
> total 32
> 16 .
je n'ai pas encore eu le temps d'analyser mes logs et si mes souvenirs sont
bons, sur un systeme unix, il n'existe pas de fragmentation concernant des
fichiers.
bref, je ne m'explique toujours pas pourquoi j'avais cette
difference de taille sur mes deux disques.
je vais analyser mes logs, mais si vous avez un éclair de genie, je veux
bien le partager :)
bonjour
non j'ai essayé aussi ces options, ca ne changeait rien.
La situation est revenue a la normale apres un redemarrage de la machine. Il
reste quand meme que sur un disque le dossier lost+found fait 4 octects, sur
l'autre 16
ls -1asR /bkp/www/ > ~/bkp.txt
ls -1asR /var/www/ > ~/var.txt
diff bkp.txt var.txt
1,2c1,2
< /bkp/www/:
< total 342971552
> /var/www/:
> total 342971564
505c505
< 4 lost+found
> 16 lost+found
507,509c507,509
< /bkp/www/lost+found:
< total 20
< 4 .
> /var/www/lost+found:
> total 32
> 16 .
je n'ai pas encore eu le temps d'analyser mes logs et si mes souvenirs sont
bons, sur un systeme unix, il n'existe pas de fragmentation concernant des
fichiers.
bref, je ne m'explique toujours pas pourquoi j'avais cette
difference de taille sur mes deux disques.
je vais analyser mes logs, mais si vous avez un éclair de genie, je veux
bien le partager :)
Matthieu a écrit, mercredi 22 mars 2006, à 07:59 :
> bonjour
bonjour,
Heu, l'unité doit être le kilo-octet, a priori (sauf POSIXLY_CORRECT, où
c'est 512 octets). M'enfin, j'ai ça avec un /lost+found/ *vide* :
Si tes */lost+found/ sont vides, je pense à une différence de taille des
blocs d'allocation --- à vérifier par «tune2fs -l» sur les deux
/dev/hd? concernées.
Filesystem UUID: e72f26c6-3dc5-40d5-a3a5-cfd5213d9a40
Free blocks: 34428670
Free inodes: 61062655
Filesystem created: Tue Jan 31 00:18:45 2006
Mount count: 5
Maximum mount count: 29
Last checked: Tue Jan 31 00:18:45 2006
Next check after: Sun Jul 30 01:18:45 2006
Directory Hash Seed: 8d340ade-ecca-4403-94f2-dfb7c0645943
Jacques L'helgoualc'h
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Matthieu a écrit, mercredi 22 mars 2006, à 07:59 :
> bonjour
bonjour,
Heu, l'unité doit être le kilo-octet, a priori (sauf POSIXLY_CORRECT, où
c'est 512 octets). M'enfin, j'ai ça avec un /lost+found/ *vide* :
Si tes */lost+found/ sont vides, je pense à une différence de taille des
blocs d'allocation --- à vérifier par «tune2fs -l» sur les deux
/dev/hd? concernées.
Filesystem UUID: e72f26c6-3dc5-40d5-a3a5-cfd5213d9a40
Free blocks: 34428670
Free inodes: 61062655
Filesystem created: Tue Jan 31 00:18:45 2006
Mount count: 5
Maximum mount count: 29
Last checked: Tue Jan 31 00:18:45 2006
Next check after: Sun Jul 30 01:18:45 2006
Directory Hash Seed: 8d340ade-ecca-4403-94f2-dfb7c0645943
Jacques L'helgoualc'h
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
Matthieu a écrit, mercredi 22 mars 2006, à 07:59 :
> bonjour
bonjour,
Heu, l'unité doit être le kilo-octet, a priori (sauf POSIXLY_CORRECT, où
c'est 512 octets). M'enfin, j'ai ça avec un /lost+found/ *vide* :
Si tes */lost+found/ sont vides, je pense à une différence de taille des
blocs d'allocation --- à vérifier par «tune2fs -l» sur les deux
/dev/hd? concernées.
Filesystem UUID: e72f26c6-3dc5-40d5-a3a5-cfd5213d9a40
Free blocks: 34428670
Free inodes: 61062655
Filesystem created: Tue Jan 31 00:18:45 2006
Mount count: 5
Maximum mount count: 29
Last checked: Tue Jan 31 00:18:45 2006
Next check after: Sun Jul 30 01:18:45 2006
Directory Hash Seed: 8d340ade-ecca-4403-94f2-dfb7c0645943
Jacques L'helgoualc'h
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
> Si tes */lost+found/ sont vides, je pense à une différence de taille des
> blocs d'allocation --- à vérifier par «tune2fs -l» sur les deux
> /dev/hd? concernées.
*diff /root/b1.txt /root/c1.txt*
15,16c15,16
< Free blocks: 34428672
< Free inodes: 61062657
> Free blocks: 34428670
> Free inodes: 61062655
*df*
/dev/hdb1 480719056 343004368 113295488 76% /var/www
/dev/hdc1 480719056 343004376 113295480 76% /bkp/www
et voici les informations que j'ai eu lors de mon dernier reboot dans *
/var/log/messages* concernant les disques dont je vous parle...
...
Mar 22 07:58:44 localhost kernel: hdb: HDS725050KLAT80, ATA DISK drive
Mar 22 07:58:44 localhost kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Mar 22 07:58:44 localhost kernel: hdc: HDS725050KLAT80, ATA DISK drive
Mar 22 07:58:44 localhost kernel: ide1 at 0x170-0x177,0x376 on irq 15
Mar 22 07:58:44 localhost kernel: hdb: max request size: 1024KiB
Mar 22 07:58:44 localhost kernel: hdb: Host Protected Area detected.
Mar 22 07:58:44 localhost kernel: ^Icurrent capacity is 976771055 sectors
(500106 MB)
Mar 22 07:58:44 localhost kernel: ^Inative capacity is 976773168 sectors
(500107 MB)
Mar 22 07:58:44 localhost kernel: hdb: 976771055 sectors (500106 MB)
w/7663KiB Cache, CHS`801/255/63, UDMA(133)
Mar 22 07:58:44 localhost kernel: /dev/ide/host0/bus0/target1/lun0: p1
Mar 22 07:58:44 localhost kernel: hdc: max request size: 1024KiB
Mar 22 07:58:44 localhost kernel: hdc: 976773168 sectors (500107 MB)
w/7663KiB Cache, CHS`801/255/63, UDMA(33)
Mar 22 07:58:44 localhost kernel: /dev/ide/host0/bus1/target0/lun0: p1
...
la je suis un peu perplexe
Pourquoi les disques ne font pas la meme taille alors que ce sont exactement
les memes modeles? Est ce que la difference d'UDMA - qui soit dit en passant
me laisse aussi perplexe - peut etre a l'origine du probleme. J'imagines que
non, mais n'ayant pas la science infuse... :)
je vous joins aussi mes logs *smartd* concernant ces deux disques, peut etre
que cela peut vous aider a comprendre, moi ca me laisse perplexe :)
> Si tes */lost+found/ sont vides, je pense à une différence de taille des
> blocs d'allocation --- à vérifier par «tune2fs -l» sur les deux
> /dev/hd? concernées.
*diff /root/b1.txt /root/c1.txt*
15,16c15,16
< Free blocks: 34428672
< Free inodes: 61062657
> Free blocks: 34428670
> Free inodes: 61062655
*df*
/dev/hdb1 480719056 343004368 113295488 76% /var/www
/dev/hdc1 480719056 343004376 113295480 76% /bkp/www
et voici les informations que j'ai eu lors de mon dernier reboot dans *
/var/log/messages* concernant les disques dont je vous parle...
...
Mar 22 07:58:44 localhost kernel: hdb: HDS725050KLAT80, ATA DISK drive
Mar 22 07:58:44 localhost kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Mar 22 07:58:44 localhost kernel: hdc: HDS725050KLAT80, ATA DISK drive
Mar 22 07:58:44 localhost kernel: ide1 at 0x170-0x177,0x376 on irq 15
Mar 22 07:58:44 localhost kernel: hdb: max request size: 1024KiB
Mar 22 07:58:44 localhost kernel: hdb: Host Protected Area detected.
Mar 22 07:58:44 localhost kernel: ^Icurrent capacity is 976771055 sectors
(500106 MB)
Mar 22 07:58:44 localhost kernel: ^Inative capacity is 976773168 sectors
(500107 MB)
Mar 22 07:58:44 localhost kernel: hdb: 976771055 sectors (500106 MB)
w/7663KiB Cache, CHS`801/255/63, UDMA(133)
Mar 22 07:58:44 localhost kernel: /dev/ide/host0/bus0/target1/lun0: p1
Mar 22 07:58:44 localhost kernel: hdc: max request size: 1024KiB
Mar 22 07:58:44 localhost kernel: hdc: 976773168 sectors (500107 MB)
w/7663KiB Cache, CHS`801/255/63, UDMA(33)
Mar 22 07:58:44 localhost kernel: /dev/ide/host0/bus1/target0/lun0: p1
...
la je suis un peu perplexe
Pourquoi les disques ne font pas la meme taille alors que ce sont exactement
les memes modeles? Est ce que la difference d'UDMA - qui soit dit en passant
me laisse aussi perplexe - peut etre a l'origine du probleme. J'imagines que
non, mais n'ayant pas la science infuse... :)
je vous joins aussi mes logs *smartd* concernant ces deux disques, peut etre
que cela peut vous aider a comprendre, moi ca me laisse perplexe :)
> Si tes */lost+found/ sont vides, je pense à une différence de taille des
> blocs d'allocation --- à vérifier par «tune2fs -l» sur les deux
> /dev/hd? concernées.
*diff /root/b1.txt /root/c1.txt*
15,16c15,16
< Free blocks: 34428672
< Free inodes: 61062657
> Free blocks: 34428670
> Free inodes: 61062655
*df*
/dev/hdb1 480719056 343004368 113295488 76% /var/www
/dev/hdc1 480719056 343004376 113295480 76% /bkp/www
et voici les informations que j'ai eu lors de mon dernier reboot dans *
/var/log/messages* concernant les disques dont je vous parle...
...
Mar 22 07:58:44 localhost kernel: hdb: HDS725050KLAT80, ATA DISK drive
Mar 22 07:58:44 localhost kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Mar 22 07:58:44 localhost kernel: hdc: HDS725050KLAT80, ATA DISK drive
Mar 22 07:58:44 localhost kernel: ide1 at 0x170-0x177,0x376 on irq 15
Mar 22 07:58:44 localhost kernel: hdb: max request size: 1024KiB
Mar 22 07:58:44 localhost kernel: hdb: Host Protected Area detected.
Mar 22 07:58:44 localhost kernel: ^Icurrent capacity is 976771055 sectors
(500106 MB)
Mar 22 07:58:44 localhost kernel: ^Inative capacity is 976773168 sectors
(500107 MB)
Mar 22 07:58:44 localhost kernel: hdb: 976771055 sectors (500106 MB)
w/7663KiB Cache, CHS`801/255/63, UDMA(133)
Mar 22 07:58:44 localhost kernel: /dev/ide/host0/bus0/target1/lun0: p1
Mar 22 07:58:44 localhost kernel: hdc: max request size: 1024KiB
Mar 22 07:58:44 localhost kernel: hdc: 976773168 sectors (500107 MB)
w/7663KiB Cache, CHS`801/255/63, UDMA(33)
Mar 22 07:58:44 localhost kernel: /dev/ide/host0/bus1/target0/lun0: p1
...
la je suis un peu perplexe
Pourquoi les disques ne font pas la meme taille alors que ce sont exactement
les memes modeles? Est ce que la difference d'UDMA - qui soit dit en passant
me laisse aussi perplexe - peut etre a l'origine du probleme. J'imagines que
non, mais n'ayant pas la science infuse... :)
je vous joins aussi mes logs *smartd* concernant ces deux disques, peut etre
que cela peut vous aider a comprendre, moi ca me laisse perplexe :)