Werden kurzlebige Dateien auf die Festplatte geschrieben?

Mein Programm erstellt viele kleine kurzlebige Dateien. Sie werden normalerweise innerhalb einer Sekunde nach der Erstellung gelöscht. Die Dateien befinden sich in einem ext4-Dateisystem, das von einer echten Festplatte unterstützt wird. Ich weiß, dass Linux regelmäßig ( pdflush) schmutzige Seiten auf die Festplatte spült . Da meine Dateien nur von kurzer Dauer sind, werden sie höchstwahrscheinlich nicht zwischengespeichert pdflush. Meine Frage ist, verursacht mein Programm viele Festplattenschreibvorgänge? Mein Anliegen ist das Leben meiner Festplatte.

Da die Dateien klein sind, nehmen wir an, dass die Summe ihrer Größe kleiner als dirty_bytesund ist dirty_background_bytes.

In Ext4 ist das Standardjournal aktiviert, dh das Metadatenjournal. Ich möchte auch wissen, ob die Metadaten oder die Daten auf die Festplatte geschrieben sind.

Ein einfaches Experiment mit ext4:

Erstellen Sie ein 100-MB-Image ...

# dd if=/dev/zero of=image bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.0533049 s, 2.0 GB/s

Machen Sie es zu einem Loop-Gerät ...

# losetup -f --show image
/dev/loop0

Dateisystem erstellen und bereitstellen ...

# mkfs.ext4 /dev/loop0
# mount /dev/loop0 /mnt/tmp

Machen Sie eine Art Lauf mit kurzlebigen Dateien. (Ändern Sie dies in eine beliebige Methode.)

for ((x=0; x<1000; x++))
do
    (echo short-lived-content-$x > /mnt/tmp/short-lived-file-$x
     sleep 1
     rm /mnt/tmp/short-lived-file-$x ) &
done

Umount, Sync, Unloop.

# umount /mnt/tmp
# sync
# losetup -d /dev/loop0

Überprüfen Sie den Bildinhalt.

# strings image | grep short-lived-file | tail -n 3
short-lived-file-266
short-lived-file-895
short-lived-file-909
# strings image | grep short-lived-content | tail -n 3

In meinem Fall wurden alle Dateinamen aufgelistet, aber keiner der Dateiinhalte. Also wurden nur die Inhalte nicht geschrieben.

Wenn Sie nicht über ein Solid-State-Laufwerk sprechen, wird eine hohe Anzahl von Festplattenschreibvorgängen nicht der dominierende Faktor für die Lebensdauer des Laufwerks sein.

Wenn Sie Festplattenschreibvorgänge wirklich vermeiden möchten, schauen Sie in tmpfs ,

Nein, sie werden in der Regel nicht geschrieben. Dies liegt daran, dass der Cache verschmutzte Seiten löscht, wenn eine von zwei Bedingungen erfüllt ist:

1. Die Daten sind danach veraltet /proc/sys/vm/dirty_writeback_centisecs, standardmäßig 5 Sekunden.

2. Es gibt zu wenig Speicher für den Cache, um die Daten zu speichern, mehr als dirty_ratioschmutzige Seiten im Cache (standardmäßig 20%).

Auf einem System mit viel freiem Speicher und wenig Schreibverkehr, abgesehen von Ihren kleinen Dateien, die in weniger als 5 Sekunden gelöscht werden, werden die Daten nicht gelöscht.

Ob kurzlebige Dateien auf die Festplatte geschrieben werden oder nicht, hängt nicht nur vom Standardverhalten des Kernel-Dateicaches ab, sondern auch von Details der Implementierung des Dateisystemtreibers und den Mount-Optionen des Dateisystems. Es ist möglich, das System so zu konfigurieren, dass immer alles sofort auf die Festplatte geschrieben wird (im Wesentlichen DOS-ähnliches Verhalten).

Ein Dateisystem, das das Verhalten, an dem Sie interessiert sind, hervorhebt (sogenannte "verzögerte Zuweisung"), ist XFS. Damit können Sie mehr oder weniger sicher sein (da an anderer Stelle keine lustigen Konfigurationsoptionen vorhanden sind), dass Blöcke, die nur zu gelöschten Dateien gehören, ohne Zwischenzugriff auf die Festplatte im Speicher wiederverwendet werden. XFS möchte möglicherweise weiterhin sein Metadatenjournal aktualisieren (das ziemlich häufig auf die Festplatte geschrieben wird. Da es sich bei dem XFS-Journal jedoch nur um Metadaten handelt, ist es klein genug, um auf einem anderen, schnellen Gerät wie dem gefundenen batteriegepufferten RAM festgelegt zu werden auf vielen RAID-Controllern).

Aufgrund dieses Verhaltens ist es nicht ungewöhnlich, dass nach einer plötzlichen Stromunterbrechung vollständig ausgelöste, aber ansonsten legitim aussehende Dateien (Größe und andere intakte Metadaten) auf einem XFS-Dateisystem gefunden werden. Dies ist ein Kostenfaktor für die Unterstützung schneller "semi-temporärer" Dateivorgänge.

Eine Theorie

Im Allgemeinen endet ein Systemaufruf, der auf ein Dateisystem zugreift, ziemlich schnell in der vom Dateisystemtreiber definierten Methode (angehängt an "struct inode_operations" und "struct file_operations", wenn der VFS-Treiber registriert ist). Was danach passiert, liegt allein im Ermessen der Implementierung des Dateisystems. In der Regel wird etwas verwendet, das dem folgenden Ansatz ähnelt (dieses einfache Beispiel stammt vom Linux-FAT-Treiber):

if (IS_DIRSYNC(dir))
    (void)fat_sync_inode(dir);
else
    mark_inode_dirty(dir);

Wenn das Dateisystem im "Synchronisierungs" -Modus bereitgestellt wird, werden alle Änderungen sofort auf die Festplatte übertragen (in diesem Fall über fat_sync_inode ()). Andernfalls wird der Block als "verschmutzt" markiert und verbleibt im Speichercache, bis er bei einer angemessenen Gelegenheit geleert wird.

Daher ist es unmöglich, das Systemverhalten in Bezug auf vorübergehende Dateien vorherzusagen, ohne die Optionen für die Dateisystembereitstellung zu berücksichtigen und den Quellcode seiner Implementierung zu überprüfen (dies gilt natürlich meistens für alle Arten von exotischen Dateisystemen, die sich hauptsächlich im eingebetteten Raum befinden). .