rsync ändert bei Ziel atime und ctime obwohl das Ziel ext3 FS mit noatime und nodiratime gemountet ist

[Pierre Bernhardt]

Hallo,

ich habe ein merkwürdiges Verhalten das ich mir nicht erklären kann. Das Source und Targes-System ist ein aktuelles
Debian 9. Die Synchronisation wird mit rsync über ssh durchgeführt. rsync ist 3.1.2 (aktuellste 3.1.3).

Die Sourcedatei in dem zu syncenden Verzeichnis ändert sich nicht. Die Zieldatei wird nicht neu übertragen.
Wegen --noatime wird auf dem Sourcesystem die atime und ctime nicht geändert. Aber Sie wird auf dem Target-
system geändert. Das wäre soweit wohl auch normal.
Damit ich das verhindere habe ich allerdings das Zieldateisystem mit noatime und nodiratime gemountet.
Wärend ein cat und ls die atime und ctime jeweils nicht anfässt ändert sich beim rsync diese beiden
Zeiten jedes mal.

Kann mir das jemand erklären?
Ist das ein Bug?
Und wo müsste man den bug unsiedeln? Im Kernel oder bei rsync?

PS: Ich habe auch versucht dem Zielrsync mittels Option --noatime mitzuteilen das das Ziel auch nicht
agefasst werde soll. Allerdings sagt schon die manpage, das --noatime nur das Source betrachtet und
nicht das Ziel. Es war einfach ein test.

Hier nochmal meine Systeme(hoffe das es ausreicht):

Source (nihilnihil):
***@nihilnihil:~/bin$ uname -a
Linux nihilnihil 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64 GNU/Linux
***@nihilnihil:~/bin$ cat /etc/debian_version
9.5
***@nihilnihil:~/bin$ rsync --version
rsync version 3.1.2 protocol version 31
Copyright (C) 1996-2015 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
append, ACLs, xattrs, iconv, symtimes, prealloc

rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.


Target (file):
***@file:~$ uname -a
Linux file 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64 GNU/Linux
***@file:~$ cat /etc/debian_version
9.5
***@file:~$ rsync --version
rsync version 3.1.2 protocol version 31
Copyright (C) 1996-2015 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
append, ACLs, xattrs, iconv, symtimes, prealloc

rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.


Hier die recht einfachen tests.

Inital kein Verzeichnis und keine Datei weder auf nihilnihil noch auf file.

***@nihilnihil:~$ mkdir dir
***@nihilnihil:~$ touch dir/file
***@nihilnihil:~$ stat dir dir/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:26:47.651971031 +0200
Modifiziert: 2018-10-11 14:26:52.487962329 +0200
Geändert : 2018-10-11 14:26:52.487962329 +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 : -

Dann rsync von nihilnihil auf file

***@nihilnihil:~$ rsync --stats --info=DEL2,NAME1,STATS2 --modify-window=2 --noatime --delete --delete-during -aHAX -e "${SSHCOMMAND}" --remote-option='--noatime' ~/dir/ "pierre@${TARGETHOST}:~/dir/"
created directory /home/pierre/dir
./
file

Number of files: 2 (reg: 1, dir: 1)
Number of created files: 2 (reg: 1, dir: 1)
Number of deleted files: 0
Number of regular files transferred: 1
Total file size: 0 bytes
Total transferred file size: 0 bytes
Literal data: 0 bytes
Matched data: 0 bytes
File list size: 0
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 133
Total bytes received: 88

sent 133 bytes received 88 bytes 63.14 bytes/sec
total size is 0 speedup is 0.00

Source ändert sich nicht:

***@nihilnihil:~$ stat dir dir/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: 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 : -

Target mtime ist gleich, der ctime und atime sind neuer mehr oder minder wie erwartet (keine nanosekunden da meines wissens erst ab 3.1.3 verfügbar):

***@file:~$ stat dir dir/file
File: dir
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: ca03h/51715d Inode: 8519839 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 1000/ pierre) Gid: ( 1000/ pierre)
Access: 2018-10-11 14:27:29.000000000 +0200
Modify: 2018-10-11 14:26:52.000000000 +0200
Change: 2018-10-11 14:27:29.000000000 +0200
Birth: -
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-11 14:27:29.000000000 +0200
Modify: 2018-10-11 14:26:52.000000000 +0200
Change: 2018-10-11 14:27:29.000000000 +0200
Birth: -

Neuer rsync ohne geänderte Source:

***@nihilnihil:~$ rsync --stats --info=DEL2,NAME1,STATS2 --modify-window=2 --noatime --delete --delete-during -aHAX -e "${SSHCOMMAND}" --remote-option='--noatime' ~/dir/ "pierre@${TARGETHOST}:~/dir/"

Number of files: 2 (reg: 1, dir: 1)
Number of created files: 0
Number of deleted files: 0
Number of regular files transferred: 0
Total file size: 0 bytes
Total transferred file size: 0 bytes
Literal data: 0 bytes
Matched data: 0 bytes
File list size: 0
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 87
Total bytes received: 19

sent 87 bytes received 19 bytes 30.29 bytes/sec
total size is 0 speedup is 0.00
***@nihilnihil:~$ stat dir dir/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: 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 : -

Aber auf dem Ziel hat sich atime und ctime geändert:

***@file:~$ stat dir dir/file
File: dir
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: ca03h/51715d Inode: 8519839 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 1000/ pierre) Gid: ( 1000/ pierre)
Access: 2018-10-11 14:30:41.000000000 +0200
Modify: 2018-10-11 14:26:52.000000000 +0200
Change: 2018-10-11 14:30:41.000000000 +0200
Birth: -
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-11 14:30:41.000000000 +0200
Modify: 2018-10-11 14:26:52.000000000 +0200
Change: 2018-10-11 14:30:41.000000000 +0200
Birth: -

Es wäre schön wenn mir jemand weiter helfen könnte und wie ich das Verhalten abstellen könnte, wenn es
möglich ist.

Danke schon mal,
Pierre

[Markus Kolb]

Post by Pierre Bernhardt
Hallo,
ich habe ein merkwürdiges Verhalten das ich mir nicht erklären kann.
Das Source und Targes-System ist ein aktuelles
Debian 9. Die Synchronisation wird mit rsync über ssh durchgeführt.
rsync ist 3.1.2 (aktuellste 3.1.3).
Die Sourcedatei in dem zu syncenden Verzeichnis ändert sich nicht. Die
Zieldatei wird nicht neu übertragen.
Wegen --noatime wird auf dem Sourcesystem die atime und ctime nicht
geändert. Aber Sie wird auf dem Target-
system geändert. Das wäre soweit wohl auch normal.
Damit ich das verhindere habe ich allerdings das Zieldateisystem mit
noatime und nodiratime gemountet.
Wärend ein cat und ls die atime und ctime jeweils nicht anfässt ändert
sich beim rsync diese beiden
Zeiten jedes mal.
Kann mir das jemand erklären?
Ist das ein Bug?
Und wo müsste man den bug unsiedeln? Im Kernel oder bei rsync?

[...]

Post by Pierre Bernhardt
Danke schon mal
Pierre

Hi Pierre,

reiche doch bitte noch die Ausgabe des "mount" Befehls als root ohne
Argumente am Ziel-Host nach!
Ansonsten wäre das ein Bug im Bereich des Filesystems im Kernel, denke
ich.

Aber du weißt, dass noatime das nodiratime beinhaltet? Also du
nodiratime nicht extra angeben musst, bzw. evt. je nach Reihenfolge
unterschiedliche Ergebnisse erzielt werden...
Es könnte somit sein, dass dein nodiratime das noatime überschreibt und
somit nicht mehr für Files gültig ist.
Da bin ich mir aber nicht ganz sicher.
Habe jetzt auf die Schnelle auch keinen Hinweis gefunden wie das
definiert ist.
Wäre aber einen Versuch wert.

sg

[Pierre Bernhardt]

Post by Pierre Bernhardt
Hallo,

...
/dev/xvda3 on /home type ext3 (rw,noatime,nodiratime,errors=remount-ro,data=ordered)
...
***@file:~# grep home /etc/fstab
/dev/xvda3 /home ext3 noatime,nodiratime,errors=remount-ro 0 1

Es könnte somit sein, dass dein nodiratime das noatime überschreibt und somit nicht mehr für Files gültig ist.

Generell scheint es aber zu funktionieren. Ein kleiner Test auf /home auf dem Zielsystem:
***@file:~$ touch testfile
***@file:~$ stat testfile
File: testfile
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: ca03h/51715d Inode: 2316953 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ pierre) Gid: ( 1000/ pierre)
Access: 2018-10-11 23:24:37.000000000 +0200
Modify: 2018-10-11 23:24:37.000000000 +0200
Change: 2018-10-11 23:24:37.000000000 +0200
Birth: -
***@file:~$ cat testfile
***@file:~$ stat testfile
File: testfile
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: ca03h/51715d Inode: 2316953 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ pierre) Gid: ( 1000/ pierre)
Access: 2018-10-11 23:24:37.000000000 +0200
Modify: 2018-10-11 23:24:37.000000000 +0200
Change: 2018-10-11 23:24:37.000000000 +0200
Birth: -

Der cat hat die atime nicht geändert.

Es wird aber immer mysteriöser:
Wenn ich den rsync auf ein komplettes Verzeichnis los lasse sind nicht alle atimes
verändert worden. Ich werde mir das nochmal genauer ansehen aber derzeit habe
ich noch keine Idee warum das so ist.

Hier mal ein Beispiel zweier Dateien. Bei der ersten wurde die atime aktualisiert,
bei der 2. nicht (und die ctime, aber das ist ja normal wenn die atime geändert
wurde).

Erst mal das source-System, dann das Target system:

Source:

***@nihilnihil:~/WinWork$ stat dir1/201507.ods
Datei: dir1/201507.ods
Größe: 140682 Blöcke: 288 EA Block: 4096 reguläre Datei
Gerät: fd0ah/64778d Inode: 5587275 Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--) Uid: ( 1000/ pierre) Gid: ( 1000/ pierre)
Zugriff : 2018-02-18 11:22:13.405129970 +0100
Modifiziert: 2015-08-03 00:00:06.445754076 +0200
Geändert : 2018-02-18 11:22:13.405129970 +0100
Geburt : -
***@nihilnihil:~/WinWork$ stat dir2/20120322_Lieferschein.pdf
Datei: dir2/20120322_Lieferschein.pdf
Größe: 280861 Blöcke: 560 EA Block: 4096 reguläre Datei
Gerät: fd0ah/64778d Inode: 6316071 Verknüpfungen: 1
Zugriff: (0640/-rw-r-----) Uid: ( 1000/ pierre) Gid: ( 1000/ pierre)
Zugriff : 2018-02-18 11:21:30.472858410 +0100
Modifiziert: 2012-04-07 00:12:48.000000000 +0200
Geändert : 2018-02-18 11:21:30.472858410 +0100
Geburt : -

Target

***@file:~/WinWork$ stat dir1/201507.ods
File: dir1/201507.ods
Size: 140682 Blocks: 288 IO Block: 4096 regular file
Device: ca03h/51715d Inode: 2375915 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ pierre) Gid: ( 1000/ pierre)
Access: 2018-10-11 23:30:37.000000000 +0200
Modify: 2015-08-03 00:00:06.000000000 +0200
Change: 2018-10-11 23:30:37.000000000 +0200
Birth: -
***@file:~/WinWork$ stat dir2/20120322_Lieferschein.pdf
File: dir2/20120322_Lieferschein.pdf
Size: 280861 Blocks: 560 IO Block: 4096 regular file
Device: ca03h/51715d Inode: 14974990 Links: 1
Access: (0640/-rw-r-----) Uid: ( 1000/ pierre) Gid: ( 1000/ pierre)
Access: 2013-01-03 23:59:33.000000000 +0100
Modify: 2012-04-07 00:12:48.000000000 +0200
Change: 2013-01-03 23:59:33.000000000 +0100
Birth: -

Die echten Pfadnamen habe ich durch dir1 und dir2 oben ersetzt. Ich wollte
nicht alles von mir preis geben ;-)

Nach einem kompletten rsync wurden jedenfalls offensichtlich etliche inodes
angepasst, und etliche nicht. Im Moment läuft jetzt aber erst mal ein
Backup und daher lasse ich weiters Testen für die Nacht.

MfG,
Pierre

[Martin Steigerwald]

Post by Pierre Bernhardt
ich habe ein merkwürdiges Verhalten das ich mir nicht erklären kann.
Das Source und Targes-System ist ein aktuelles Debian 9. Die
Synchronisation wird mit rsync über ssh durchgeführt. rsync ist 3.1.2
(aktuellste 3.1.3).
Die Sourcedatei in dem zu syncenden Verzeichnis ändert sich nicht. Die
Zieldatei wird nicht neu übertragen. Wegen --noatime wird auf dem
Sourcesystem die atime und ctime nicht geändert. Aber Sie wird auf
dem Target- system geändert. Das wäre soweit wohl auch normal.
Damit ich das verhindere habe ich allerdings das Zieldateisystem mit
noatime und nodiratime gemountet. Wärend ein cat und ls die atime und
ctime jeweils nicht anfässt ändert sich beim rsync diese beiden
Zeiten jedes mal.
Kann mir das jemand erklären?
Ist das ein Bug?
Und wo müsste man den bug unsiedeln? Im Kernel oder bei rsync?

Ich wüsste nicht, wieso das ein Bug sein sollte.

Die Mount-Optionen verhindern nicht, dass rsync die Zeiten der Dateien
anpasst.

Post by Pierre Bernhardt
--modify-window=2 --noatime --delete --delete-during -aHAX -e
"${SSHCOMMAND}" --remote-option='--noatime' ~/dir/

Schau dir mal genau an, welche Optionen "-a" enthält. Dann hast du,
denke ich, die Antwort auf deine Frage.

Ciao,

[Pierre Bernhardt]

Post by Martin Steigerwald
Die Mount-Optionen verhindern nicht, dass rsync die Zeiten der Dateien
anpasst.

Ja, das ist richtig. Es kann diese explizit ändern, wenn es das
wollte. Aber siehe Antwort unten...

Post by Martin Steigerwald

Post by Pierre Bernhardt
--modify-window=2 --noatime --delete --delete-during -aHAX -e
"${SSHCOMMAND}" --remote-option='--noatime' ~/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.
Die atime und ctime werden dabei nicht angefasst (siehe auch
rsync --help):

rsync --help |grep -- ,\ --times
-t, --times preserve modification times

Oder meintest Du etwas anderes?

MfG,
Pierre

[Martin Steigerwald]

Post by Pierre Bernhardt

Post by Martin Steigerwald

Post by Pierre Bernhardt
--modify-window=2 --noatime --delete --delete-during -aHAX -e
"${SSHCOMMAND}" --remote-option='--noatime' ~/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.

Die ctime passt das Dateisystem immer an, sobald sich der "Status" des
Dateisystem-Objektes ändert. Also Inhalt geändert, Datei umbenannt,
Rechte angepasst usw. Da gibt es meines Wissens auch keine Mount-Option,
um das komplett abzuschalten. Die Mount-Option "lazytime" verzögert
diese Updates nur. Keine Ahnung, inwiefern bereits in Kernel 4.9
Dateisysteme diese Option unterstützen (siehe Manpage von "mount"). Ext4
vielleicht.

Was die "atime" anbetrifft, weiß ich nicht exakt, wie sich ein
Dateisystem verhält, wenn es *ohnehin* entweder die "mtime" oder die
"ctime" ändert. Möglicherweise wirkt "noatime" nur bei Lesezugriffen.
Die Manpage von "mount" erwähnt dazu nichts. Jedoch war das Unterbinden
von "atime"-Updates bei Lesezugriffen soweit ich das verstanden hab die
Haupt-Motivation hinter "noatime". Also eine Option für mehr Performance
durch weniger Schreibzugriffe. Wenn das Dateisystem die Inode ohnehin
anfasst, um andere Zeitstempel zu ändern… spielt es Performance-
technisch auch keine Rolle mehr, inwiefern es die "atime" anfasst.

So oder so: Was für ein Problem versuchst Du eigentlich zu lösen? Oder
andersherum gefragt: Wieso stört dich, dass Linux die atime anpasst?

Ich mounte meine Haupt-Dateisysteme mit "noatime" und schaue
dementsprechend auch nicht auf die "atime". Die interessiert mich
einfach nicht mehr.

Falls Dich das wirklich entsprechend interessiert, empfehle sich Dir auf
der "fsdevel"-Mailingliste der Kernel-Entwickler in Englisch direkt
nachzufragen. Möglicherweise ist das Verhalten der einzelnen
Dateisysteme da auch nicht ganz einheitlich. Ich weiß nicht, wie viel
davon im VFS (Virtual Filesystem Switch, einer Abstraktionsschicht mit
gemeinsamen Funktionen für alle Dateisysteme) implementiert ist.

Ciao,

[Pierre Bernhardt]

Post by Martin Steigerwald
Die ctime passt das Dateisystem immer an, sobald sich der "Status" des
Dateisystem-Objektes ändert. Also Inhalt geändert, Datei umbenannt,
Rechte angepasst usw. Da gibt es meines Wissens auch keine Mount-Option,
um das komplett abzuschalten. Die Mount-Option "lazytime" verzögert
diese Updates nur. Keine Ahnung, inwiefern bereits in Kernel 4.9
Dateisysteme diese Option unterstützen (siehe Manpage von "mount"). Ext4
vielleicht.Ich habe so verstanden das eine Anpassung der atime auch generell eine

Anpassung der ctime nachzieht. Das kann ich auch nachvollziehen.
Daher wollte ich versuchen das die atime sich nicht ändert.

Post by Martin Steigerwald
Was die "atime" anbetrifft, weiß ich nicht exakt, wie sich ein
Dateisystem verhält, wenn es *ohnehin* entweder die "mtime" oder die
"ctime" ändert. Möglicherweise wirkt "noatime" nur bei Lesezugriffen.

Ja, von diesem Punkt ausgesehen hast Du recht. Die mtime ändert sich nie,
es ist immer nur die atime und vermutlich daher dann auch die ctime.

Post by Martin Steigerwald
So oder so: Was für ein Problem versuchst Du eigentlich zu lösen? Oder
andersherum gefragt: Wieso stört dich, dass Linux die atime anpasst?

Ich synce mein lokales Dateisystem it rsync auf einen fileserver.
Dort wird dann ein Backup Band täglich durchgeführt. Ich hatte mich
immer gewundert warum, wenn ich ein rsync durchführe, dann immer
GiBytes im Backup landen wenn ich doch nur ein paar MiByte geändert
habe. Das liegt daran das auch eine inode-Änderung zu einem Backup
führt um auch diese korrekt im Backup zu haben.
Im Moment habe ich die Strategie geändert, das änderungen der atime
und mtime nicht zu einem Backup führen. Das löst erst mal mein
Problem ist aber nur Flickzeug. Ich würde gerne lieber an die Ursache
des Problems heran treten und es lösen.
Aber gut, ich will keine Diskussion darüber starten und unnötig
Ressourcen verschwenden sondern lieber voran kommen ;-)

Post by Martin Steigerwald
Ich mounte meine Haupt-Dateisysteme mit "noatime" und schaue
dementsprechend auch nicht auf die "atime". Die interessiert mich
einfach nicht mehr.
Falls Dich das wirklich entsprechend interessiert, empfehle sich Dir auf
der "fsdevel"-Mailingliste der Kernel-Entwickler in Englisch direkt
nachzufragen. Möglicherweise ist das Verhalten der einzelnen
Dateisysteme da auch nicht ganz einheitlich. Ich weiß nicht, wie viel
davon im VFS (Virtual Filesystem Switch, einer Abstraktionsschicht mit
gemeinsamen Funktionen für alle Dateisysteme) implementiert ist.

Ja, das könnte ich machen, aber inzwischen vermute ich das das
Verhalten eher ein Problem in rsync ist. Ich habe festgestellt das
das anpassen der atime nicht generell bei allen Dateien und Verzeichnissen
durchgeführt wird sondern nur bei einigen. Siehe mehr dazu in einem
meiner anderen Antworten. Wenn ich das genauer bestimmen kann
werde ich mich entweder an die rsync-Mailingliste oder an fsdevel wenden.
Danke für den Tipp.

MfG,
Pierre

[Pierre Bernhardt]

Post by Pierre Bernhardt

Post by Martin Steigerwald

Post by Pierre Bernhardt
--modify-window=2 --noatime --delete --delete-during -aHAX -e
"${SSHCOMMAND}" --remote-option='--noatime' ~/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:

***@nihilnihil:~$ echo ls -l /home/pierre//~/dir
ls -l /home/pierre//~/dir
***@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/ ***@192.168.2.5:~/dir/
***@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/ ***@192.168.2.5:~/dir/
***@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):

***@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 : -
***@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.

***@nihilnihil:~$ touch -t 201810121200.00 dir2
***@nihilnihil:~$ touch -t 201810121200.00 dir2/file

...(initialsync transferiert Datei und Verzeichnis wird aktualisiert, hier nicht wichtig)
...(Eher nun der 2. Sync:)

***@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:

***@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)

***@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

[Martin Steigerwald]

Post by Pierre Bernhardt
1. Warum werden überhaupt auf dem Zielsystem die Nanosekunden beim
setzen der mtime abgeschnitten (gleiches OS Debian 9, gleiches FS
ext3)?

Ext3 kann keine Nanosekunden speichern.

Bei im Hauptspeicher gecachten Zeiten siehst Du Nanosekunden, bei allem,
was auf den Datenträger kommt, ist es nur noch Sekunden-genau.

Ext4, XFS und BTRFS bieten Nanosekunden-Auflösung.

[Pierre Bernhardt]

Post by Martin Steigerwald

Post by Pierre Bernhardt
1. Warum werden überhaupt auf dem Zielsystem die Nanosekunden beim
setzen der mtime abgeschnitten (gleiches OS Debian 9, gleiches FS
ext3)?

Ext3 kann keine Nanosekunden speichern.
Bei im Hauptspeicher gecachten Zeiten siehst Du Nanosekunden, bei allem,
was auf den Datenträger kommt, ist es nur noch Sekunden-genau.
Ext4, XFS und BTRFS bieten Nanosekunden-Auflösung.

Naja ich denke doch das ext3 es kann wenn man einen neueren Kernel verwendet und
die Inode Size 256 Byte statt 128 Byte ist. Man kann einige Features
des ext4 dann auch in ext3 verwenden, wie die Nanosekunden.
Deswegen bin ich auch nicht gleich darauf gekommen das das aber nicht
/normal/ ist. Ich hatte es ja einfach hingenommen das das /-FS welches
bei mir noch ext3 ist die Nanoseconds ausgegeben hat.

Ich habe dazu was bereits in einer Antwort an mich selber geschrieben.
Schau Dir die Mail gerne mal an ;-) Die Konvertierung hat ewig
gedauert ist aber jetzt fertig. Nach dem nächsten rsyncs weiss ich mehr.
Ich lass vorsichtshalber nochmal einen fsck laufen.

MfG,
Pierre Bernhardt

[Martin Steigerwald]

Post by Pierre Bernhardt

Post by Martin Steigerwald
Ext3 kann keine Nanosekunden speichern.
Bei im Hauptspeicher gecachten Zeiten siehst Du Nanosekunden, bei
allem, was auf den Datenträger kommt, ist es nur noch
Sekunden-genau.
Ext4, XFS und BTRFS bieten Nanosekunden-Auflösung.

Naja ich denke doch das ext3 es kann wenn man einen neueren Kernel
verwendet und die Inode Size 256 Byte statt 128 Byte ist. Man kann
einige Features des ext4 dann auch in ext3 verwenden, wie die
Nanosekunden.
Deswegen bin ich auch nicht gleich darauf gekommen das das aber nicht
/normal/ ist. Ich hatte es ja einfach hingenommen das das /-FS welches
bei mir noch ext3 ist die Nanoseconds ausgegeben hat.

Hmmm, okay. In aktuellen Distributionen kommt das Ext4-Modul auch für
Ext3 zum Einsatz, so auch in Debian.

So oder so sehe ich keinen Sinn mehr darin, Ext3 statt Ext4 zu nutzen.

CIao,

[Elimar Riesebieter]

Post by Martin Steigerwald
So oder so sehe ich keinen Sinn mehr darin, Ext3 statt Ext4 zu nutzen.

Der PowerPC Bootloader yaboot kann keine Daten von ext4 lesen. Hier
ist für /boot ext3 angebracht. Ich vermute das noch mehr solcher
althergebrachten Anwendungen maximal ext3 vertragen... ext3 lässt
sich auch mit den neuesten Kerneln formatieren. Hierfür notwendig ist
das ext4 Modul. Das ext3 Modul ist nur noch aus
Kompatibilitätsgründen in den neueren Kernel und verweist auf das
ext4 Modul.

Elimar

[Pierre Bernhardt]

Post by Pierre Bernhardt
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.
1. Warum werden überhaupt auf dem Zielsystem die Nanosekunden beim setzen der
mtime abgeschnitten (gleiches OS Debian 9, gleiches FS ext3)?
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.

Ich konnte zumindest diese Problem lösen. Ich will mal meine Untersuchungs-
details nicht verheimlichen, wo es nun schon aufgeschrieben habe. Für
Alle die nur am Ergebnis interressier sind, schaut Euch einfach nur das
Ende der Mail an :-)
Oder ganz kurz: / wurde mit 256 Inodessize angelegt, während home noch
älter ist und noch mit 128 Inodesize angelegt wurde. Ein Konvertierung
des ext3 mit tune2fs -I 256 ist letztendlich die Lösung für dieses Punktes.

Auf dem /home FS des Zielservers werden Dateien scheinbar alle ohne Nano-
Sekunden abgelegt:

***@file:~$ touch bla
***@file:~$ stat bla
File: bla
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: ca03h/51715d Inode: 2316965 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ pierre) Gid: ( 1000/ pierre)
Access: 2018-10-12 12:54:46.000000000 +0200
Modify: 2018-10-12 12:54:46.000000000 +0200
Change: 2018-10-12 12:54:46.000000000 +0200
Birth: -
***@file:~$ df -h bla
Filesystem Size Used Avail Use% Mounted on
/dev/xvda3 561G 524G 12G 98% /home

Im /-FS allerdings ist alles ok:

***@file:~$ stat /var/tmp/bla
File: /var/tmp/bla
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: ca02h/51714d Inode: 8254 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ pierre) Gid: ( 1000/ pierre)
Access: 2018-10-12 12:59:37.745603278 +0200
Modify: 2018-10-12 12:59:37.745603278 +0200
Change: 2018-10-12 12:59:37.745603278 +0200
Birth: -
***@file:~$ df -h /var/tmp/bla
Filesystem Size Used Avail Use% Mounted on
/dev/xvda2 4.9G 3.0G 1.8G 64% /

***@file:~$ mount |grep xvd
/dev/xvda2 on / type ext3 (rw,noatime,nodiratime,errors=remount-ro,stripe=256,data=ordered)
/dev/xvda3 on /home type ext3 (rw,noatime,nodiratime,errors=remount-ro,data=ordered)

Ich hatte dann den Verdacht das es was mit dem ext3 zu tun haben könnte und mal mit
tune2fs verglichen. Aber ich sehe hier nicht woran es liegen könnte:

***@file:~# diff <(tune2fs -l /dev/xvda2) <(tune2fs -l /dev/xvda3)
3,4c3,4
< Last mounted on: /
< Filesystem UUID: b4468535-f2bd-4128-ae5e-1bc160679206
---

Post by Pierre Bernhardt
Last mounted on: /home
Filesystem UUID: 44a27150-df7a-405b-a0b7-c55f1d9420c9

13,17c13,17
< Inode count: 327680
< Block count: 1310720
< Reserved block count: 57651
< Free blocks: 726504
< Free inodes: 275878
---

Post by Pierre Bernhardt
Inode count: 74711040
Block count: 149422080
Reserved block count: 6622234
Free blocks: 12197578
Free inodes: 73365584

21c21
< Reserved GDT blocks: 63
---

Post by Pierre Bernhardt
Reserved GDT blocks: 988

24c24
< Inodes per group: 8192
---

Post by Pierre Bernhardt
Inodes per group: 16384

26,30c26,28
< RAID stride: 128
< RAID stripe width: 256
< Filesystem created: Fri Sep 16 00:05:12 2011
< Last mount time: Tue Sep 18 23:24:12 2018
< Last write time: Tue Sep 18 23:24:10 2018
---

Post by Pierre Bernhardt
Filesystem created: Fri May 23 13:55:53 2008
Last mount time: Tue Sep 18 23:24:14 2018
Last write time: Tue Sep 18 23:24:14 2018

32,33c30,31
< Maximum mount count: 31
< Last checked: Fri May 11 01:36:55 2018
---

Post by Pierre Bernhardt
Maximum mount count: 28
Last checked: Fri May 11 01:37:30 2018

35,36c33,34
< Next check after: Wed Nov 7 00:36:55 2018
< Lifetime writes: 142 GB
---

Post by Pierre Bernhardt
Next check after: Wed Nov 7 00:37:30 2018
Lifetime writes: 584 GB

40,42c38
< Inode size: 256
< Required extra isize: 28
< Desired extra isize: 28
---

Post by Pierre Bernhardt
Inode size: 128

44,46c40,41
< First orphan inode: 41191
< Default directory hash: half_md4
< Directory Hash Seed: 284b7e93-f2bc-4dc4-a1e7-cf17b51d6221
---

Post by Pierre Bernhardt
Default directory hash: tea
Directory Hash Seed: d777f5cb-43a1-492a-b796-655ba508a9ab

Das /home ist schon relativ alt und wurde vielleicht mal als ext2
erzeugt. Das kann ich aber mit Sicherheit nicht sagen. Aber
das könnte die Ursache sein warum auf dem /home keine Nanosekunden
verwendet werden.

Also habe ich es mal nachgeprüft:

102400 Bytes (102 kB, 100 KiB) kopiert, 0,000499446 s, 205 MB/s
***@nihilnihil:~# dd if=/dev/zero of=/bla bs=1k count=100k
102400+0 Datensätze ein
102400+0 Datensätze aus
104857600 Bytes (105 MB, 100 MiB) kopiert, 0,166585 s, 629 MB/s
***@nihilnihil:~# mke2fs /bla
mke2fs 1.43.4 (31-Jan-2017)
Geräteblöcke werden verworfen: erledigt
Ein Dateisystems mit 102400 (1k) Blöcken und 25688 Inodes wird erzeugt.
UUID des Dateisystems: aed173e8-110b-4aae-bdb7-134a30ab7606
Superblock-Sicherungskopien gespeichert in den Blöcken:
8193, 24577, 40961, 57345, 73729

beim Anfordern von Speicher für die Gruppentabellen: erledigt
Inode-Tabellen werden geschrieben: erledigt
Die Superblöcke und die Informationen über die Dateisystemnutzung werden
geschrieben: erledigt

***@nihilnihil:~# tune2fs -l /bla
tune2fs 1.43.4 (31-Jan-2017)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: aed173e8-110b-4aae-bdb7-134a30ab7606
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 25688
Block count: 102400
Reserved block count: 5120
Free blocks: 97600
Free inodes: 25677
First block: 1
Block size: 1024
Fragment size: 1024
Reserved GDT blocks: 256
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 1976
Inode blocks per group: 247
Filesystem created: Fri Oct 12 13:19:02 2018
Last mount time: n/a
Last write time: Fri Oct 12 13:19:02 2018
Mount count: 0
Maximum mount count: -1
Last checked: Fri Oct 12 13:19:02 2018
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Default directory hash: half_md4
Directory Hash Seed: 333807f0-25e2-4057-97b5-879f57fa767b

***@nihilnihil:~# mkdir /media/bla
***@nihilnihil:~# mount -o loop /bla /media/bla
***@nihilnihil:~# cd /media/bla

***@nihilnihil:/media/bla# touch file1
***@nihilnihil:/media/bla# stat file1
Datei: file1
Größe: 0 Blöcke: 0 EA Block: 1024 reguläre leere Datei
Gerät: 700h/1792d Inode: 12 Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Zugriff : 2018-10-12 13:19:57.000000000 +0200
Modifiziert: 2018-10-12 13:19:57.000000000 +0200
Geändert : 2018-10-12 13:19:57.000000000 +0200
Geburt : -
***@nihilnihil:/media/bla# cd
***@nihilnihil:~# umount /media/bla

Soweit wie erwartet da das ext2 keine Nanoseconds unterstützt.

Nun die Konvertierung und ein weiterer Test:

***@nihilnihil:~# tune2fs -j /bla
tune2fs 1.43.4 (31-Jan-2017)
Journal-Inodes werden erzeugt: erledigt
***@nihilnihil:~# mount -o loop /bla /media/bla
***@nihilnihil:~# cd -
/media/bla
***@nihilnihil:/media/bla# stat file1
Datei: file1
Größe: 0 Blöcke: 0 EA Block: 1024 reguläre leere Datei
Gerät: 700h/1792d Inode: 12 Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Zugriff : 2018-10-12 13:19:57.000000000 +0200
Modifiziert: 2018-10-12 13:19:57.000000000 +0200
Geändert : 2018-10-12 13:19:57.000000000 +0200
Geburt : -
***@nihilnihil:/media/bla# touch file2
***@nihilnihil:/media/bla# stat file2
Datei: file2
Größe: 0 Blöcke: 0 EA Block: 1024 reguläre leere Datei
Gerät: 700h/1792d Inode: 13 Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Zugriff : 2018-10-12 13:21:13.000000000 +0200
Modifiziert: 2018-10-12 13:21:13.000000000 +0200
Geändert : 2018-10-12 13:21:13.000000000 +0200
Geburt : -

Also scheint es wirklich so zu sein das ein konvertiertes ext2 keine Nanosekunden
unterstützt.

Jetzt frage ich mich ob ich das FS neu anlegen muss oder ob ich es doch noch *richtig*
ins ext3 konvertieren kann das auch Nanosekunden unterstützt.

Jetzt war ich also auf der Suche nach Hinweisen zu Unterschieden und habe
Hinweise gefunden das eigentlich ext3 genau wie ext2 gar keine nanosekunden
unterstützen dürfte. Da kommt dann schon die nächste Frage auf, warum
dann bei mir im /-FS Nanosekunden bei einem stat angezeigt werden, aber im
konvertierten FS nicht?

Nur zur Sicherheit habe ich nochmal ein ext3 direkt erzeugt um nachzusehen,
ob dort die Nanosekunden verwendet werden:

***@nihilnihil:~# mkfs.ext3 /bla3
mke2fs 1.43.4 (31-Jan-2017)
Geräteblöcke werden verworfen: erledigt
Ein Dateisystems mit 102400 (1k) Blöcken und 25688 Inodes wird erzeugt.
UUID des Dateisystems: 6fe20a2a-ab37-4dde-a3a0-57e8580fb149
Superblock-Sicherungskopien gespeichert in den Blöcken:
8193, 24577, 40961, 57345, 73729

beim Anfordern von Speicher für die Gruppentabellen: erledigt
Inode-Tabellen werden geschrieben: erledigt
Das Journal (4096 Blöcke) wird angelegt: erledigt
Die Superblöcke und die Informationen über die Dateisystemnutzung werden
geschrieben: erledigt

(reverse-i-search)`mount': man ^Cunt
***@nihilnihil:~# mkdir /media/bla3
***@nihilnihil:~# mount -o loop /bla3 /media/bla3
***@nihilnihil:~# cd /media/bla3
***@nihilnihil:/media/bla3# touch file
***@nihilnihil:/media/bla3# stat file
Datei: file
Größe: 0 Blöcke: 0 EA Block: 1024 reguläre leere Datei
Gerät: 701h/1793d Inode: 12 Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Zugriff : 2018-10-12 13:41:02.000000000 +0200
Modifiziert: 2018-10-12 13:41:02.000000000 +0200
Geändert : 2018-10-12 13:41:02.000000000 +0200
Geburt : -

Wie es meinen Recherchen nach sein sollte werden keine Nanosekunden verwendet.
Jetzt wird es doch etwas unheimlich…nur um sicher zu gehen:

***@nihilnihil:/media/bla3# mount |grep bla
/bla on /media/bla type ext3 (rw,relatime,data=ordered)
/bla3 on /media/bla3 type ext3 (rw,relatime,data=ordered)
***@nihilnihil:/media/bla3# mount |grep root
/dev/mapper/rootdg-root on / type ext3 (rw,relatime,errors=remount-ro,data=ordered)
/dev/mapper/rootdg-var on /var type ext3 (rw,relatime,data=ordered)
***@nihilnihil:/media/bla3# cd /
***@nihilnihil:/# touch file
***@nihilnihil:/# stat file
Datei: file
Größe: 0 Blöcke: 0 EA Block: 4096 reguläre leere Datei
Gerät: fd01h/64769d Inode: 412 Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Zugriff : 2018-10-12 13:43:11.845354286 +0200
Modifiziert: 2018-10-12 13:43:11.845354286 +0200
Geändert : 2018-10-12 13:43:11.845354286 +0200
Geburt : -

Jetzt bin ich verwirrt…aber im Wikipedia-Artikel über ext4 lese ich gerade, das
man einige Features aus ext4 bereits in ext3 nutzen kann. Der Grund könnte
sein das die neuen Kernel den ext4 Treiber für ext3 nutzen.
Also mal nachforschen…
Und es ist tatsächlich so das man einfach mit tune2fs -I 256 die Größe
der Inodes ändern kann und dann auch Nanosekunden unterstützt werden.
Ich habe es testweise mal auf dem oben angelegten ext3-FS getan und mir
das Ergebnis angesehen:



***@nihilnihil:/etc# tune2fs -l /bla3
tune2fs 1.43.4 (31-Jan-2017)
Filesystem volume name: <none>
Last mounted on: /media/bla3
Filesystem UUID: 6fe20a2a-ab37-4dde-a3a0-57e8580fb149
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 25688
Block count: 102400
Reserved block count: 5120
Free blocks: 93487
Free inodes: 25676
First block: 1
Block size: 1024
Fragment size: 1024
Reserved GDT blocks: 256
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 1976
Inode blocks per group: 247
Filesystem created: Fri Oct 12 13:40:27 2018
Last mount time: Fri Oct 12 13:40:53 2018
Last write time: Fri Oct 12 13:53:26 2018
Mount count: 0
Maximum mount count: -1
Last checked: Fri Oct 12 13:53:26 2018
Check interval: 0 (<none>)
Lifetime writes: 29 kB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 42d6c745-4a54-4629-a4ac-8d9151f772ac
Journal backup: inode blocks
***@nihilnihil:/etc# tune2fs -I 256 /bla3
tune2fs 1.43.4 (31-Jan-2017)
Resizing inodes could take some time.
Proceed anyway (or wait 5 seconds) ? (y,N) y<Verarbeitung läuft
Die Inode-Größe wird auf 256 gesetzt
***@nihilnihil:/etc# tune2fs -l /bla3
tune2fs 1.43.4 (31-Jan-2017)
Filesystem volume name: <none>
Last mounted on: /media/bla3
Filesystem UUID: 6fe20a2a-ab37-4dde-a3a0-57e8580fb149
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 25688
Block count: 102400
Reserved block count: 5120
Free blocks: 90276
Free inodes: 25676
First block: 1
Block size: 1024
Fragment size: 1024
Reserved GDT blocks: 256
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 1976
Inode blocks per group: 494
Filesystem created: Fri Oct 12 13:40:27 2018
Last mount time: Fri Oct 12 13:40:53 2018
Last write time: Fri Oct 12 13:55:12 2018
Mount count: 0
Maximum mount count: -1
Last checked: Fri Oct 12 13:53:26 2018
Check interval: 0 (<none>)
Lifetime writes: 6727 kB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 42d6c745-4a54-4629-a4ac-8d9151f772ac
Journal backup: inode blocks
***@nihilnihil:/etc# mount -o loop /bla3 /media/bla3


Ein wenig verwirrend ist das man y drücken soll, aber wenn man es macht der
Befehl abbrechen kann. Schon komisch. Vorher muss auf jedenfall noch ein
fsck -f erfolgen, sonst funktioniert die Migration nicht.

Die Migration scheint jedenfalls erfolgreich zu sein:

***@nihilnihil:/media/bla3# stat file
Datei: file
Größe: 0 Blöcke: 0 EA Block: 1024 reguläre leere Datei
Gerät: 701h/1793d Inode: 12 Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Zugriff : 2018-10-12 13:41:02.000000000 +0200
Modifiziert: 2018-10-12 13:41:02.000000000 +0200
Geändert : 2018-10-12 13:41:02.000000000 +0200
Geburt : -
***@nihilnihil:/media/bla3# touch file2
***@nihilnihil:/media/bla3# stat file2
Datei: file2
Größe: 0 Blöcke: 0 EA Block: 1024 reguläre leere Datei
Gerät: 701h/1793d Inode: 13 Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Zugriff : 2018-10-12 13:58:26.067946935 +0200
Modifiziert: 2018-10-12 13:58:26.067946935 +0200
Geändert : 2018-10-12 13:58:26.067946935 +0200
Geburt : -

Damit werde ich die Migration nach dem nächsten Backup auf dem /home des
Fileservers vornehmen. Dann sollten auch die mtime-Zeitanpassungen ein Ende
haben. Auf Dauer wäre aber wohl eine Migration zu ext4 auch mal sinnvoll.

Ich fand diesen Artikel übrigens dazu ganz hilreich:
https://kernelnewbies.org/Ext4#head-3891522e0601162aab24c73c1f148a1e28c6a9d4

MfG,
Pierre

[Sven Hartge]

Post by Pierre Bernhardt
ich habe ein merkwürdiges Verhalten das ich mir nicht erklären kann.
Das Source und Targes-System ist ein aktuelles Debian 9. Die
Synchronisation wird mit rsync über ssh durchgeführt. rsync ist 3.1.2
(aktuellste 3.1.3).
Die Sourcedatei in dem zu syncenden Verzeichnis ändert sich nicht. Die
Zieldatei wird nicht neu übertragen. Wegen --noatime wird auf dem
Sourcesystem die atime und ctime nicht geändert. Aber Sie wird auf dem
Target- system geändert. Das wäre soweit wohl auch normal. Damit ich
das verhindere habe ich allerdings das Zieldateisystem mit noatime und
nodiratime gemountet. Wärend ein cat und ls die atime und ctime
jeweils nicht anfässt ändert sich beim rsync diese beiden Zeiten jedes
mal.

"noatime" und "nodiratime" heißt ja nur, dass beim Zugriff auf die
Dateien die access time nicht automatisch gesetzt wird.

Es heißt dagegen *nicht*, dass das Feature im Dateisystem komplett
abgeschaltet ist, Programme, wie z.B. rsync, können die Werte dennoch
verändern. Warum auch nicht.

Post by Pierre Bernhardt
Kann mir das jemand erklären? Ist das ein Bug?

Nein, works as intended.

S°

[Pierre Bernhardt]

Post by Sven Hartge
"noatime" und "nodiratime" heißt ja nur, dass beim Zugriff auf die
Dateien die access time nicht automatisch gesetzt wird.
Es heißt dagegen *nicht*, dass das Feature im Dateisystem komplett
abgeschaltet ist, Programme, wie z.B. rsync, können die Werte dennoch
verändern. Warum auch nicht.

Ja, das hatte ich auch schon vermutet. Ich dachte daher, das wenn
das so ist, das rsync das explizit anpassen müsste. Das würde ja
aber auch bedeuten das rsync sowas wie einen touch -a zusätzlich
machen müsste (natürlich nicht direkt mit touch sondern mit den
systemcalls (?) utime, utimes, futimes, futimens ), oder?

Post by Sven Hartge

Post by Pierre Bernhardt
Kann mir das jemand erklären? Ist das ein Bug?

Nein, works as intended.

Dann würde ich einen Bug bei rsync aufmachen wollen. Ich denke nicht
das es so gewollt ist da es ja offensichtlich explicit gesetzt wird.

Aber ich würde erst mal untersuchen wollen was überhaupt auf rsync-
Seite passiert. Mal sehen, mit strace sollte ich ja sehen können
of rsync dort einen der systemcalls entsprechen nutzt und sonst
noch so anstellt. Ich bin da nicht erfahren aber hoffe ich
sehe was oder jemand kann mir einen Tipp geben wo es dann hakt.
Wenn rsync das explizip nutzt kann ich ja hoffentlich recht einfach
patchen ;-)

MfG,
Pierre

[Markus Kolb]

Vielleicht hilft dir das:
https://bugzilla.samba.org/show_bug.cgi?id=7249#c6

[Pierre Bernhardt]

Vielleicht hilft dir das: https://bugzilla.samba.org/show_bug.cgi?id=7249#c6

Vielen Dank, den hatte ich bei meiner Suche gar nicht gesehen ;-)
Das beschreibt scheinbar ziemlich genau mein Problem.
Ich werde mich mal da ran hängen und nachfragen was denn gepatcht wurde um
das Problem zu beheben.

MfG,
Pierre

[Harald Weidner]

Hallo,

Post by Pierre Bernhardt

Post by Sven Hartge

Post by Pierre Bernhardt
Kann mir das jemand erklären? Ist das ein Bug?

Nein, works as intended.

Dann würde ich einen Bug bei rsync aufmachen wollen. Ich denke nicht
das es so gewollt ist da es ja offensichtlich explicit gesetzt wird.
Aber ich würde erst mal untersuchen wollen was überhaupt auf rsync-
Seite passiert. Mal sehen, mit strace sollte ich ja sehen können
of rsync dort einen der systemcalls entsprechen nutzt und sonst
noch so anstellt. Ich bin da nicht erfahren aber hoffe ich
sehe was oder jemand kann mir einen Tipp geben wo es dann hakt.

Ein Blick in den Sourcecode hilft weiter.

rsync mit der Option -t (oder -a, was -t beinhaltet), verwendet je nachdem
wie es compiliert wurde, einen der System Calls utime(), utimes, utimensat()
oder ähnliches, um die Zeitstempel zu modifizieren. Z.B. hier:

https://git.samba.org/?p=rsync.git;a=blob;f=syscall.c;hb=1eb7a7061af2f91149233937f3db066d303c7684#l415

Bei diesen System Calls wird immer die mtime und atime gemeinsam gesetzt.
rsync setzt dabei die mtime wie auf der Quellseite gelesen, und setzt die
atime auf den aktuellen Zeitstempel.

Ob das jetzt ein Bug ist, ist Definitionssache. Ich nehme mal an, das wurde
so gemacht, weil die atime der Quelldatei im rsync-Protokoll gar nicht
übertragen wird. Es gäbe sicherlich auch andere Möglichkeiten, hier zu einem
sinnvollen Wert für die atime zu kommen.

Mit der ctime hat rsync nichts zu tun. Die wird vom Kernel bzw. vom
Filesystem-Treiber gesetzt. Soweit ich weiß, gibt es keine portable
Möglichkeit, die ctime eigenmächtig zu verändern.

Post by Pierre Bernhardt
Wenn rsync das explizip nutzt kann ich ja hoffentlich recht einfach
patchen ;-)

Patchen kannst du, wie du willst. Ist schließlich Open Source. ;-)

Ich würde aber an deiner Stelle eher die Backup-Strategie überdenken. Eine
Datei neu zu sichern, weil sich ihre atime oder ctime geändert hat, halte
ich nicht für sinnvoll. Auf inhaltliche Änderungen deutet ausschließlich
eine Änderung der mtime hin.

Gruß, Harald

[Pierre Bernhardt]

Post by Pierre Bernhardt
Hallo,

Hallo

Post by Pierre Bernhardt
Ein Blick in den Sourcecode hilft weiter.
rsync mit der Option -t (oder -a, was -t beinhaltet), verwendet je nachdem
wie es compiliert wurde, einen der System Calls utime(), utimes, utimensat()
https://git.samba.org/?p=rsync.git;a=blob;f=syscall.c;hb=1eb7a7061af2f91149233937f3db066d303c7684#l415
Bei diesen System Calls wird immer die mtime und atime gemeinsam gesetzt.
rsync setzt dabei die mtime wie auf der Quellseite gelesen, und setzt die
atime auf den aktuellen Zeitstempel.

Ja, ich bin schon ein wenig weiter (siehe andere Mail). Ich hatte nicht
angenommen das die mtime überhaupt geändert werde muss.

Post by Pierre Bernhardt
Ob das jetzt ein Bug ist, ist Definitionssache. Ich nehme mal an, das wurde
so gemacht, weil die atime der Quelldatei im rsync-Protokoll gar nicht
übertragen wird. Es gäbe sicherlich auch andere Möglichkeiten, hier zu einem
sinnvollen Wert für die atime zu kommen.

Laut debug-Option von rsync wird nur die mtime angepasst. Was tatsächlich
passiert darauf hattest Du ja schon einen Hinweis gegeben.

Post by Pierre Bernhardt

Post by Pierre Bernhardt
Wenn rsync das explizip nutzt kann ich ja hoffentlich recht einfach
patchen ;-)

Patchen kannst du, wie du willst. Ist schließlich Open Source. ;-)
Ich würde aber an deiner Stelle eher die Backup-Strategie überdenken. Eine
Datei neu zu sichern, weil sich ihre atime oder ctime geändert hat, halte
ich nicht für sinnvoll. Auf inhaltliche Änderungen deutet ausschließlich
eine Änderung der mtime hin.

Derzeit habe ich das so gemacht ;-). Eigentlich wollte ich ja nur die
inode-Infos gleich halten ohne das gleich der Inhalt mit gebackupt wird
(also update nur im Backupindex).
Aber das ist eine andere Geschichte ;-) Fürs Backup habe ich erst mal
einen Workaround gefunden, aber die Geschichte will ich nun doch noch
zu Ende heraus finden.

MfG,
Pierre