staging.inyokaproject.org

Code zum Testen in e. leeren Verzeichnis:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 2 Dateien mit minimalem Inhalt füllen:
echo a > 1.txt
echo b > 2.txt 
# ... und ausgeben
cat ?.txt
# mit stat die Zugriffszeiten ausgeben (access time)
stat -c "%n %x" ?.txt 
sleep 1
# Nur Datei 1 erneut ausgeben
cat 1.txt 
# erneut Zugriffszeit prüfen
stat -c "%n %x" ?.txt 
# Beide Dateien ändern und nochmal ausgebn: 
echo c >> 1.txt
echo c >> 2.txt 
cat ?.txt 
stat -c "%n %x" ?.txt 

Ich habe mich bisher nie tiefergehend mit der access-time beschäftigt und stieß heute überraschend auf ein Phänomen.

Wenn ich eine Datei erstmalig mit cat lese, wird dieser Zeitpunkt als Accesstime protokolliert.

Output:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

a
b
1.txt 2022-11-15 23:01:16.123742289 +0100
2.txt 2022-11-15 23:01:16.123742289 +0100
a
1.txt 2022-11-15 23:01:16.123742289 +0100
2.txt 2022-11-15 23:01:16.123742289 +0100
a
c
b
c
1.txt 2022-11-15 23:01:17.131744425 +0100
2.txt 2022-11-15 23:01:17.131744425 +0100

Dann gebe ich nach einer Wartezeit von 1s Datei 1.txt erneut aus (Zeile 5), aber die Accesszeit ändert sich nicht (Z. 6).

Ich vermutete daher, dass der Inhalt gecacht ist, und die Datei nicht wirklich neu gelesen wird und daher der Zeitstempel auch nicht aktualisiert wird.

Lesen von info stat hat mir nicht weitergeholfen. Eine Hypothese war dann, dass ich, wenn ich die Datei aus einem anderen Terminal heraus lese, die Accesstime vielleicht aktualisiert wird, weil der andere Prozess in einem eigenen Speicherbereich läuft, vielleicht aber auch nicht, weil der Dateisystemzugriff womöglich auf einem höheren Level stattfindet und dennoch caching stattfindet - entweder auf OS-Level, womöglich aber sogar auf Partitionslevel.

Weiß da jmd. genaueres?

Das Experiment ergab, dass auch in einer neuen xterm-Session ein Lesezugriff keine Aktualisierung der Accesstime bewirkt.

Das hat mich etwas überrascht.

Drive ist eine Intel-SSD, nicht die jüngste, Laptop, Partition btrfs. Inxi-Infos:

1
2
3
4
5
6
7
8

Drives:
  Local Storage: total: 1.09 TiB used: 295.41 GiB (26.5%)
  ID-1: /dev/sda vendor: Intel model: SSDSC2BW180A3L size: 167.68 GiB
  # ...
Partition:
  # ...
  ID-2: /home size: 47.12 GiB used: 46.32 GiB (98.3%) fs: btrfs
    dev: /dev/sda6

An btrfs liegt es nicht - in einer VM mit ext4 hatte ich das gleiche Phänomen.

Mit Caching hat das eher nix zu tun. Schau Dir mal die Mount-Optionen Deines Dateisystems an. Ziemlich wahrscheinlich, dass "relatime" gesetzt ist. Erklärung in der Manpage von mount.

Danke.

rklm schrieb:

Mit Caching hat das eher nix zu tun. Schau Dir mal die Mount-Optionen Deines Dateisystems an. Ziemlich wahrscheinlich, dass "relatime" gesetzt ist. Erklärung in der Manpage von mount.

Aus dem Abschnitt zu relatime:

Since Linux 2.6.30, the kernel defaults to the behavior provided by this option (unless noatime was specified), and the strictatime option is required to obtain traditional semantics.

Dieses neue Standardverhalten dürfte wohl einige User irritieren. Ich verstehe die Intention, dass man Traffic einsparen will und daher sparsam mit dem Aktualisieren der atime umgeht. Das macht aber nur wirklich Sinn bei sehr häufigen Lesezugriffen (zB auf Servern). Weiß jemand, warum man dies nun quasi allen Anwendern auf's Auge gedrückt hat?

EDIT: Vergesst es. Das ist ja ewig her mit dem Wechsel...