Ist mv atomar auf meinem fs?


12

Wie kann ich überprüfen, ob mvmein fs (ext4) atomar ist?

Das Betriebssystem ist Red Hat Enterprise Linux Server Version 6.8.

Wie kann ich das im Allgemeinen überprüfen? Ich habe mich umgesehen und nicht festgestellt, ob mein Betriebssystem Standard-POSIX ist.


Hast du es versucht strace?
Wildcard

Antworten:


8

Interessanterweise scheint die Antwort "Es kommt darauf an" zu sein.

Um es klar, mvangegeben zu

Das mvDienstprogramm muss Aktionen ausführen, die der rename() Funktion entsprechen

In der Umbenennungsfunktionsspezifikation heißt es:

Diese rename()Funktion entspricht für reguläre Dateien der im ISO C-Standard definierten. Durch die Aufnahme hier wird diese Definition um Aktionen für Verzeichnisse erweitert und das Verhalten angegeben, wenn der neue Parameter eine bereits vorhandene Datei benennt. Diese Spezifikation erfordert, dass die Wirkung der Funktion atomar ist.

Aber die neueste ISO C-Spezifikation für rename()Staaten:

7.21.4.2 Die renameFunktion

Zusammenfassung

#include <stdio.h>
int rename(const char *old, const char *new);

Beschreibung

Die renameFunktion bewirkt, dass die Datei, deren Name die Zeichenfolge ist, auf die gezeigt wird old, fortan unter dem Namen bekannt ist, der durch die Zeichenfolge angegeben wird, auf die gezeigt wird new. Auf die genannte Datei kann unter diesem Namen oldnicht mehr zugegriffen werden. Wenn newvor dem Aufruf der renameFunktion eine Datei existiert, die durch die Zeichenfolge benannt ist, auf die durch verwiesen wird , ist das Verhalten implementierungsdefiniert.

Kehrt zurück

Die renameFunktion gibt Null zurück, wenn die Operation erfolgreich ist, ungleich Null, wenn sie fehlschlägt. In diesem Fall ist die Datei, wenn sie zuvor vorhanden war, immer noch unter ihrem ursprünglichen Namen bekannt.

Beachten Sie überraschenderweise, dass keine explizite Anforderung an die Atomizität besteht. Es ist möglicherweise an einer anderen Stelle im neuesten öffentlich verfügbaren C-Standard erforderlich, aber ich konnte es nicht finden. Wenn jemand eine solche Anforderung finden kann, sind Änderungen und Kommentare mehr als willkommen.

Siehe auch Ist rename () atomar?

Per Linux-Manpage :

Wenn es newpathbereits vorhanden ist, wird es atomar ersetzt, sodass es an keinem Punkt newpathfehlt, an dem ein anderer Prozess, der versucht, darauf zuzugreifen , es findet. Es wird jedoch wahrscheinlich ein Fenster geben, in dem beide oldpathund newpathauf die umbenannte Datei verweisen.

Die Linux-Manpage behauptet, dass das Ersetzen der Datei atomar sein wird.

Das Testen und Verifizieren dieser Atomizität kann jedoch sehr schwierig sein, wenn Sie so weit gehen müssen. Sie sind sich nicht sicher, was Sie mit "Wie kann ich überprüfen, ob mv atomar ist" meinen? Möchten Sie Anforderungen / Spezifikationen / Dokumentationen, die atomar sind, oder müssen Sie sie tatsächlich testen ?

Beachten Sie außerdem, dass sich die beiden Operandendateinamen im selben Dateisystem befinden. Ich kann keine Standardbeschränkung für das mvDienstprogramm finden, um dies durchzusetzen.


Ich muss sicherstellen, dass die Bewegung atomar ist. Ist das Testen genug, um dies zu akzeptieren? Ich kann es nicht sagen. Ja, ich arbeite an einem gleichen fs (ext4 bis ext4).
Tizianoreica

1
POSIX garantiert auch keine Atomizität, aber Linux, wie die meisten Unix-Varianten, für "native" Dateisysteme wie ext4.
Gilles 'SO - hör auf böse zu sein'

1
Angesichts der Tatsache, dass ISO C nur das Verhalten eines Programms und nicht eines ganzen Systems definiert, wäre es seltsam, etwas über renameAtomizität zu sagen .
Gilles 'SO - hör auf böse zu sein'

3
Ich habe "diese Spezifikation" als Verweis auf den vorherigen Satz gelesen ("Die Aufnahme hier ... gibt das Verhalten an, wenn der neue Parameter eine bereits vorhandene Datei benennt"), der auf frühere Teile des POSIX-Dokuments verweist ("ein Link mit dem Namen new soll" bleiben für andere Threads sichtbar ... und verweisen entweder auf die Datei, auf die von new oder old verwiesen wird ... "). Mit anderen Worten, POSIX verspricht die Implementierung des ISO C-Standards und gibt zusätzliche Garantien, die über das hinausgehen, was ISO C bietet. Hilft diese Interpretation?
SimonJ

1
@Tizianoreica Ich weiß, dass dies ein alter Beitrag ist, aber ich habe gerade Ihren Kommentar gesehen und dachte, ich sollte klarstellen: Das tatsächliche Dateisystem muss das gleiche sein, damit die Umbenennung atomar ist. Nicht nur die gleiche Art von Dateisystem. zB wenn Sie /als ext4 fs und /tmpals anderes ext4 fs haben, können Sie nicht atomar von einem zum anderen mv.
Wodin vor

0

mvbasiert auf einem renameSystemaufruf und rename()ist atomar. Sie können sich die Manpage ansehen rename(2).

Sie könnten eine Antwort auf Is rename () atomic finden? auf Stapelüberlauf.

Welche Art von fs hast du benutzt?


fs ist ext4 - os bereits angegeben.
Tizianoreica

-1

Zusätzlich zur Überprüfung der Systemaufrufe und ihrer Atomizität kann dies möglicherweise inotify-toolsals Test dienen, obwohl ich nicht sicher bin, ob dies ein garantierter Beweis für die Atomizität ist.

2 Muscheln öffnen. Beobachten Sie das Zielverzeichnis des Umzugs in einem von ihnen:

inotifywait -m target/

Verschieben Sie eine Datei in das Verzeichnis im anderen:

mv foobar target/

Das inotifywaitsollte nur eine Zeile anzeigen:

target/ MOVED_TO foobar

Es scheint atomar im Vergleich zu der Antwort auf ls target/und touch target/a, die mehrzeilige Nachrichten erzeugen wie:

# the response to ls target/
target/ OPEN,ISDIR 
target/ ACCESS,ISDIR 
target/ CLOSE_NOWRITE,CLOSE,ISDIR 

PS

Ich denke, zumindest zeigt es, dass die asynchrone Multiprozess-Zusammenarbeit bei Dateien sicher ist inotify(praktisch atomar): In jedem Fall würden Sie erst antworten, nachdem Sie inotifynach der Operation das endgültige Signal gegeben haben. Beispielsweise kann ein Producer-Consumer-Setup mit einfach und sicher implementiert werden inotify.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.