Re: rsync ändert bei Ziel atime und ctime obwohl das Ziel ext3 FS mit noatime und nodiratime gemountet ist
Am 12.10.18 um 12:41 schrieb Pierre Bernhardt:> Am 12.10.18 um 10:34 schrieb Martin Steigerwald:
> 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:
pierre@file:~$ touch bla
pierre@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: -
pierre@file:~$ df -h bla
Filesystem Size Used Avail Use% Mounted on
/dev/xvda3 561G 524G 12G 98% /home
Im /-FS allerdings ist alles ok:
pierre@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: -
pierre@file:~$ df -h /var/tmp/bla
Filesystem Size Used Avail Use% Mounted on
/dev/xvda2 4.9G 3.0G 1.8G 64% /
pierre@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:
root@file:~# diff <(tune2fs -l /dev/xvda2) <(tune2fs -l /dev/xvda3)
3,4c3,4
< Last mounted on: /
< Filesystem UUID: b4468535-f2bd-4128-ae5e-1bc160679206
---
> 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
---
> Inode count: 74711040
> Block count: 149422080
> Reserved block count: 6622234
> Free blocks: 12197578
> Free inodes: 73365584
21c21
< Reserved GDT blocks: 63
---
> Reserved GDT blocks: 988
24c24
< Inodes per group: 8192
---
> 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
---
> 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
---
> 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
---
> 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
---
> Inode size: 128
44,46c40,41
< First orphan inode: 41191
< Default directory hash: half_md4
< Directory Hash Seed: 284b7e93-f2bc-4dc4-a1e7-cf17b51d6221
---
> 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
root@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
root@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
root@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
root@nihilnihil:~# mkdir /media/bla
root@nihilnihil:~# mount -o loop /bla /media/bla
root@nihilnihil:~# cd /media/bla
root@nihilnihil:/media/bla# touch file1
root@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 : -
root@nihilnihil:/media/bla# cd
root@nihilnihil:~# umount /media/bla
Soweit wie erwartet da das ext2 keine Nanoseconds unterstützt.
Nun die Konvertierung und ein weiterer Test:
root@nihilnihil:~# tune2fs -j /bla
tune2fs 1.43.4 (31-Jan-2017)
Journal-Inodes werden erzeugt: erledigt
root@nihilnihil:~# mount -o loop /bla /media/bla
root@nihilnihil:~# cd -
/media/bla
root@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 : -
root@nihilnihil:/media/bla# touch file2
root@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:
root@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
root@nihilnihil:~# mkdir /media/bla3
root@nihilnihil:~# mount -o loop /bla3 /media/bla3
root@nihilnihil:~# cd /media/bla3
root@nihilnihil:/media/bla3# touch file
root@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:
root@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)
root@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)
root@nihilnihil:/media/bla3# cd /
root@nihilnihil:/# touch file
root@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:
root@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
root@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
root@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
root@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:
root@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 : -
root@nihilnihil:/media/bla3# touch file2
root@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
Reply to: