Kann mir jemand folgendes Verhalten erklären?

$ ls /home/uo/dosenfischer/ /media/disk/dosenfischer/ /home/uo/dosenfischer/: dosenfischer_podcast_34b.mp3  dosenfischer_podcast_36.mp3 dosenfischer_podcast_34.mp3   dosenfischer_podcast_37.mp3 dosenfischer_podcast_35b.mp3  dosenfischer_podcast_38a.mp3 dosenfischer_podcast_35.mp3   dosenfischer_podcast_38.mp3 /media/disk/dosenfischer/: dosenfischer_podcast_34b.mp3  dosenfischer_podcast_36.mp3 dosenfischer_podcast_34.mp3   dosenfischer_podcast_37.mp3 dosenfischer_podcast_35b.mp3  dosenfischer_podcast_38a.mp3 dosenfischer_podcast_35.mp3   dosenfischer_podcast_38.mp3 $ diff -r /home/uo/dosenfischer/ /media/disk/dosenfischer/ $ rsync -rv --delete /home/uo/dosenfischer/ /media/disk/dosenfischer/ building file list ... done dosenfischer_podcast_34.mp3 dosenfischer_podcast_35b.mp3 dosenfischer_podcast_37.mp3 dosenfischer_podcast_38.mp3 sent 202079626 bytes  received 108 bytes  7090516.98 bytes/sec total size is 416719371  speedup is 2.06
Wieso synchronisiert rsync 4 von 8 Dateien, obwohl sie schon identisch sind? /media/disk ist eine FAT16-formatierte SD-Karte. Praktisch neu, ansonsten keine merkwürdigen Verhalten, von daher möchte ich Hardwarefehler eigentlich ausschliessen (ausserdem würden Lesefehler ja auch von diff bemerkt werden)

Das gleiche Problem hab ich noch mit 'nem 2. Verzeichnis auf der gleichen SD-Karte - in dem Fall aber viele kleine (hauptsächlich XML- und GIF-) Dateien. Eine zweite SD-Karte hab ich noch nicht versucht, hab zur Zeit nur die eine hier.

*edit* Habs jetzt nochmal mit einem per loopback gemountetem FAT16-Dateisystem versucht. Da will er sogar jedesmal alle 8 Dateien komplett neu kopieren:

$ rsync -rv --delete /home/uo/dosenfischer/ /mnt/dosenfischer/ building file list ... done dosenfischer_podcast_34.mp3 dosenfischer_podcast_34b.mp3 dosenfischer_podcast_35.mp3 dosenfischer_podcast_35b.mp3 dosenfischer_podcast_36.mp3 dosenfischer_podcast_37.mp3 dosenfischer_podcast_38.mp3 dosenfischer_podcast_38a.mp3 sent 416770784 bytes  received 196 bytes  10825220.26 bytes/sec total size is 416719371  speedup is 1.00
*edit2* Huch? Das gleiche Verhalten, wenn ich innerhalb meiner ext3-Festplatte synchronisiere… hab ich an rsync irgendwas komplett falsch verstanden? Identische Dateien sollen doch gerade NICHT neu übertragen werden?

*edit3* " und fat" ausm Betreff gelöscht.

Ideen?

Eher nur ins Blaue: diff bezieht sich nur auf den Inhalt der Datein. rsync aber auch auf Metadaten (glaub ich). Bei FAT könnten sich was an den Rechten ändern. Ansonsten gib's ja noch atime & co die sich ändern können.

Hmm, ja. Hatte ich auch schon drüber nachgedacht. Aber:

* Hab das Verhalten inzwischen ja auch auf ext3 reproduzieren können
* Ich benutz ja gerade nicht rsync -a (kurz für rsync -rlptgoD), sondern eben nur -r (–recursive) - also auch nix mit Metadaten.
* Und selbst, wenn er sich um Metadaten kümmern würde - das sind nur wenige Kilobyte, im Gegensatz zu mp3-Dateien im Megabyte-Bereich. Würde man sowohl in der Geschwindigkeit, als auch in der Zusammenfassung merken, da würde dann ein speedup-Wert von weit über 1 rauskommen.

Trotzdem Danke.

/* Hm, ob mit oder ohne "-a" … hier synct rsync die Zeit die ls -l anzeigt mit. */

ne. einmal mit a, danach listet er die Datein nicht mehr mit auf… komisch.

Hi!

Dürfte glaube ich evtl an deinem fehlendem Update-parameter von rsync liegen, habe bei uns in der Firme diverse rsyncs laufen, die z.T. server Spiegeln (mit Kolab z.b., klappt astrein!) und da müssen ~20 GB über die Leitung gecheckt werden, dauert nur 4 Minuten, da er nur die neuen Mails rüber schaufelt.

Ich benutze das so:

rsync -Crogtavzu /kolab 192.168.1xxx.yyy:/backups/kolab –delete > $LOGFULL

Hier die Parameter;
C -C, –cvs-exclude auto-ignore files in the same way CVS does
r -r, –recursive recurse into directories
o -o, –owner preserve owner (super-user only)
g -g, –group preserve group
t -t, –times preserve times
a -a, –archive archive mode; same as -rlptgoD (no -H, -A)
v verbose
z -z, –compress compress file data during the transfer
u und hier das coolste: -u, –update skip files that are newer on the receiver
–delete Das ist cool, wenn du z.b. mails auf einem server löscht, damit die auf dem backupserver auch weg sind, in deinem fall aber wohl eher uninteressant.

Falls du noch fragen hast: lukas(at)kucharski-hh.de
(Habe leider meinen login vergessen und alle Versuche verbraucht, aber ich dachte mir, dass ich dir evtl damit weiterhelfen konnte.

Grüße
Lukas


–
Having trouble in Windows? Reboot!
Having trouble in Linux? Be Root!

Hi!

Dürfte glaube ich evtl an deinem fehlendem Update-parameter von rsync liegen, habe bei uns in der Firme diverse rsyncs laufen, die z.T. server Spiegeln (mit Kolab z.b., klappt astrein!) und da müssen ~20 GB über die Leitung gecheckt werden, dauert nur 4 Minuten, da er nur die neuen Mails rüber schaufelt.

Ja, das ist für unveränderliche Dateien (wie Deine Mails und meine mp3-Dateien) eine Lösung. Im anderen (oben nur angedeuteten) Fall will ich aber Dateien synchronisieren, die möglicherweise auf beiden Seiten verändert wurden. Dabei soll immer die Datei der Quelle "gewinnen" - also genau das Verhalten ohne -u. Aber dann wird viel zu viel kopiert. Rsync erkennt nicht, wenn Dateien nicht verändert wurden. Genau das (und mehr) soll rsync laut Paper aber können. Und genau das (Datei nicht verändert) ist bei mir der häufigste Fall, es ändert sich immer nur ein kleiner Teil der Daten.

Haben die Dateien vielleicht eine ungerade Sekundenzahl in einem der Zeitpunkte (Wahrscheinlichkeit insgesamt: 7/8)? FAT16 hat nämlich nur eine Auflösung von 2 Sekunden.

Damals, als Bits noch teuer waren: 32filetime = 16datum + 16zeit = 7jahr + 4monat + 5tag + 5stunde + 6minute + 5sekunde

Roland

Siehe edit2 :P

So, aber anscheinend hab ich die Lösung. Laut paper benutzt rsync Prüfsummen, um die übertragene Datenmenge zu minimieren. (ganz kurz zusammengefasst). Bei identischen Dateien sollte somit praktisch nichts übertragen werden. Ganz unabhängig von irgendwelchen Zeitstempeln :P

Irgendwie war ich jetzt davon ausgegangen, dass das auch lokal gilt. Aber der im Paper beschriebene Algorithmus wird wohl nur angewendet, wenn Quelle oder Ziel remote sind. Macht auch irgendwie Sinn. Lokal wird einfach kopiert, ohne Rücksicht auf Verluste.

Muss ich wohl mal rsync-ssh-loopback kombinieren… oder einfach mit den zusätzlichen Schreibvorgängen auf der SD-Karte leben.

Hmpf. Hätte mir nichtmal wer ein RTFM um die Ohren hauen können?

-W, –whole-file
              With this option the incremental rsync algorithm is not used and
              the  whole  file  is  sent  as-is  instead.  The transfer may be
              faster if this option is used when  the  bandwidth  between  the
              source  and destination machines is higher than the bandwidth to
              disk  (especially  when  the  “disk”  is  actually  a  networked
              filesystem).   This is the default when both the source and des‐
              tination are specified as local paths.