Re: rsync ändert bei Ziel atime und ctime obwohl das Ziel ext3 FS mit noatime und nodiratime gemountet ist
Am 12.10.18 um 10:34 schrieb Martin Steigerwald:
> Pierre Bernhardt - 12.10.18, 00:16:
>>>> pierre@nihilnihil:~$ rsync --stats --info=DEL2,NAME1,STATS2
>>>> --modify-window=2 --noatime --delete --delete-during -aHAX -e
>>>> "${SSHCOMMAND}" --remote-option='--noatime' ~/dir/
>>>> "pierre@${TARGETHOST}:~/dir/"
>>>
>>> Schau dir mal genau an, welche Optionen "-a" enthält. Dann hast du,
>>> denke ich, die Antwort auf deine Frage.
>>
>> Leider nein. Die -a Option enthält die Optionen
>> -rlptgoD
>> Ich nehme an Du spielst auf die enthaltene Option -t für times
>> an. Leider wird aber laut man-page times nur die mtime anpassen.
Ich habe mir nun mit der --remote-option='debug ALL' option nochmal
angesehen was genau passiert und heraus gefunden das jedesmal versucht
wird die mtime anzupassen:
pierre@nihilnihil:~$ echo ls -l /home/pierre//~/dir
ls -l /home/pierre//~/dir
pierre@nihilnihil:~$ echo rsync --modify-window=2 --noatime --delete --delete-during -aHAX -e "${SSHCOMMAND}" --remote-option='--noatime --debug ALL' {,pierre@${TARGETHOST}:}"~/dir/"
rsync --modify-window=2 --noatime --delete --delete-during -aHAX -e ssh -p 22 --remote-option=--noatime --debug ALL ~/dir/ pierre@192.168.2.5:~/dir/
pierre@nihilnihil:~$ echo rsync --modify-window=2 --noatime --delete --delete-during -aHAX -e "${SSHCOMMAND}" --remote-option='--noatime --debug ALL' {,pierre@${TARGETHOST}:}~/dir/
rsync --modify-window=2 --noatime --delete --delete-during -aHAX -e ssh -p 22 --remote-option=--noatime --debug ALL /home/pierre/dir/ pierre@192.168.2.5:~/dir/
pierre@nihilnihil:~$ rsync --modify-window=2 --noatime --delete --delete-during -aHAX -e "${SSHCOMMAND}" --remote-option='--noatime --debug ALL' {,pierre@${TARGETHOST}:}~/dir/
(Server) Protocol versions: remote=31, negotiated=31
server_recv(2) starting pid=11668
[Receiver] created hashtable 5578cb9c8460 (size: 1024, keys: 32-bit)
get_local_name count=2 /home/pierre/dir/
[Receiver] change_dir(/home/pierre/dir)
generator starting pid=11668
delta-transmission enabled
recv_files(2) starting
recv_generator(.,0)
set modtime of . to (1539260812) Thu Oct 11 14:26:52 2018
recv_generator(.,1)
recv_generator(file,2)
set modtime of file to (1539260812) Thu Oct 11 14:26:52 2018
generate_files phase=1
recv_files phase=1
generate_files phase=2
recv_files phase=2
recv_files finished
generate_files phase=3
[receiver] send_msg(10, 8)
generate_files finished
Das ist verständlich wenn man erstmal davon ausgeht das ja die mtime auf den
Zielserver abgeschnitten sind (warum weiss ich derzeit noch nicht):
pierre@nihilnihil:~$ stat dir/file
Datei: dir/file
Größe: 0 Blöcke: 0 EA Block: 4096 reguläre leere Datei
Gerät: fd0ah/64778d Inode: 97492993 Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--) Uid: ( 1000/ pierre) Gid: ( 1000/ pierre)
Zugriff : 2018-10-11 14:26:52.487962329 +0200
Modifiziert: 2018-10-11 14:26:52.487962329 +0200
Geändert : 2018-10-11 14:26:52.487962329 +0200
Geburt : -
pierre@nihilnihil:~$ ssh file stat dir/file
File: dir/file
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: ca03h/51715d Inode: 8519840 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ pierre) Gid: ( 1000/ pierre)
Access: 2018-10-12 12:08:50.000000000 +0200
Modify: 2018-10-11 14:26:52.000000000 +0200
Change: 2018-10-12 12:08:50.000000000 +0200
Birth: -
Allerdings sollte durch das --modify-window=2 das eigentlich ausgenommen sein.
Möglicherweise greift die Option aber nur für das Kopieren der Datei, aber nicht
für das setzen der mtime.
Jedenfalls könnte das erklären warum bei einem rsync nicht alle atimes auf
dem Zielsystem aktualisiert werden. Ich habe auch schon mal einen Gegencheck
gemacht. Wenn ich auf dem Sourcesystem die nanosekunden abschneide und
dann synce sind danach die mtime zwischen beiden systemen gleich.
Ein weiterer Sync aktualisiert dann nicht mehr die mtime und die atime
bleibt auch wie sie ist.
pierre@nihilnihil:~$ touch -t 201810121200.00 dir2
pierre@nihilnihil:~$ touch -t 201810121200.00 dir2/file
...(initialsync transferiert Datei und Verzeichnis wird aktualisiert, hier nicht wichtig)
...(Eher nun der 2. Sync:)
pierre@nihilnihil:~$ rsync --modify-window=2 --noatime --delete --delete-during -aHAX -e "${SSHCOMMAND}" --remote-option='--noatime --debug ALL' {~/dir2/,pierre@${TARGETHOST}:~/dir/}
(Server) Protocol versions: remote=31, negotiated=31
server_recv(2) starting pid=11753
[Receiver] created hashtable 55f7f9b36460 (size: 1024, keys: 32-bit)
get_local_name count=2 /home/pierre/dir/
[Receiver] change_dir(/home/pierre/dir)
generator starting pid=11753
delta-transmission enabled
recv_files(2) starting
recv_generator(.,0)
recv_generator(.,1)
recv_generator(file,2)
generate_files phase=1
recv_files phase=1
generate_files phase=2
recv_files phase=2
recv_files finished
generate_files phase=3
[receiver] send_msg(10, 8)
generate_files finished
Das Problem scheint auch eher nur dann zu sein, wenn ich rsync für einen
Transfer auf ein remote-System einsetze.
Wenn ich rsync local synce werden die Zieldateien mit Nanosekunden erzeugt:
pierre@nihilnihil:~$ rsync --modify-window=2 --noatime --delete --delete-during -aHAX --debug ALL ~/dir/ ~/dir3/
(Server) Protocol versions: remote=31, negotiated=31
(Client) Protocol versions: remote=31, negotiated=31
[sender] created hashtable 55ca600a5370 (size: 16, keys: 64-bit)
[sender] change_dir(/home/pierre/dir)
send_files starting
server_recv(2) starting pid=97841
[Receiver] created hashtable 55ca600a5370 (size: 1024, keys: 32-bit)
get_local_name count=2 /home/pierre/dir3/
[Receiver] change_dir(/home/pierre/dir3)
generator starting pid=97841
delta-transmission disabled for local transfer or --whole-file
recv_files(2) starting
recv_generator(.,0)
set modtime of . to (1539260812) Thu Oct 11 14:26:52 2018
recv_generator(.,1)
send_files(0, /home/pierre/dir/.)
recv_generator(file,2)
generate_files phase=1
send_files(2, /home/pierre/dir/file)
sender finished /home/pierre/dir/file
recv_files(.)
recv_files(file)
set modtime of .file.HCGOao to (1539260812) Thu Oct 11 14:26:52 2018
renaming .file.HCGOao to file
[receiver] send_msg_int(100, 2)
set modtime of . to (1539260812) Thu Oct 11 14:26:52 2018
send_files phase=1
recv_files phase=1
generate_files phase=2
send_files phase=2
send files finished
total: matches=0 hash_hits=0 false_alarms=0 data=0
recv_files phase=2
recv_files finished
generate_files phase=3
[receiver] send_msg(10, 8)
generate_files finished
[sender] _exit_cleanup(code=0, file=main.c, line=1196): about to call exit(0)
pierre@nihilnihil:~$ stat dir dir3 dir/file dir3/file
Datei: dir
Größe: 4096 Blöcke: 8 EA Block: 4096 Verzeichnis
Gerät: fd0ah/64778d Inode: 1884278 Verknüpfungen: 2
Zugriff: (0755/drwxr-xr-x) Uid: ( 1000/ pierre) Gid: ( 1000/ pierre)
Zugriff : 2018-10-11 14:27:29.875895051 +0200
Modifiziert: 2018-10-11 14:26:52.487962329 +0200
Geändert : 2018-10-11 14:26:52.487962329 +0200
Geburt : -
Datei: dir3
Größe: 4096 Blöcke: 8 EA Block: 4096 Verzeichnis
Gerät: fd0ah/64778d Inode: 17416350 Verknüpfungen: 2
Zugriff: (0755/drwxr-xr-x) Uid: ( 1000/ pierre) Gid: ( 1000/ pierre)
Zugriff : 2018-10-12 12:33:29.652681170 +0200
Modifiziert: 2018-10-11 14:26:52.487962329 +0200
Geändert : 2018-10-12 12:33:29.652681170 +0200
Geburt : -
Datei: dir/file
Größe: 0 Blöcke: 0 EA Block: 4096 reguläre leere Datei
Gerät: fd0ah/64778d Inode: 97492993 Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--) Uid: ( 1000/ pierre) Gid: ( 1000/ pierre)
Zugriff : 2018-10-11 14:26:52.487962329 +0200
Modifiziert: 2018-10-11 14:26:52.487962329 +0200
Geändert : 2018-10-11 14:26:52.487962329 +0200
Geburt : -
Datei: dir3/file
Größe: 0 Blöcke: 0 EA Block: 4096 reguläre leere Datei
Gerät: fd0ah/64778d Inode: 17416351 Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--) Uid: ( 1000/ pierre) Gid: ( 1000/ pierre)
Zugriff : 2018-10-12 12:33:29.652681170 +0200
Modifiziert: 2018-10-11 14:26:52.487962329 +0200
Geändert : 2018-10-12 12:33:29.652681170 +0200
Geburt : -
Interressant deswegen weil ja angeblich nur ein
/set modtime of . to (1539260812) Thu Oct 11 14:26:52 2018/
gemacht wird, und da sind keine Nanosekunden angegeben. Also lügt der debug
oder verheimlicht zumindest diese.
Es gibt also nun 3 Fragen:
1. Warum werden überhaupt auf dem Zielsystem die Nanosekunden beim setzen der
mtime abgeschnitten (gleiches OS Debian 9, gleiches FS ext3)?
2. Warum gibt es einen unterschied beim localen rsync und dem remote rsync?
3. Warum greift hier die Option --modify-window=2 nicht und aktualisiert
die mtime überhaupt?
Zu 1. habe ich einen Verdacht: Der Remoteserver ist eine XEN DomU unter Debian
8 auf der Dom0. Möglicherweise ist das ein Grund warum keine Nanosekunden
aktualiert werden.
PS: Verzeiht mir diese detailierten Kommentare und Gedanken. Wenn ich sowas
aufschreibe kann ich besser über weitere Schritte und mögliche Ursachen und
dessen Analyse nachdenken ;-)
MfG,
Pierre
Reply to: