Welche Vorteile bietet das Hochladen von Dateien nach /tmp vor dem Verschieben in den permanenten Speicher?

Question

Beim Erstellen von Funktionen zum Verwalten von Datei-Uploads scheint es in der Programmierung üblich zu sein, die Datei zunächst in ein temporäres Verzeichnis/einen temporären Ordner hochzuladen (z. B. /tmp unter Linux). Sobald die Datei fertig ist, wird sie aus dem temporären Verzeichnis verschoben und zur Speicherung in das angegebene Verzeichnis gelegt. Einige Programmier-/Skriptsprachen legen laufende Uploads standardmäßig in /tmp ab, andere nicht. Es scheint jedoch gängige Praxis zu sein, /tmp explizit als Platzhalterverzeichnis festzulegen, bis der Upload abgeschlossen ist. Dann wird es in ein separates Verzeichnis verschoben.

Welchen Vorteil bietet die Verwendung eines temporären „Warteverzeichnisses“ zum Hochladen von Inhalten, bevor die Datei(en) zur langfristigen Speicherung auf eine andere Partition/ein anderes Verzeichnis verschoben werden?

Ich arbeite in einer Umgebung, in der (interner) Netzwerkspeicher über NFS-Mounts an virtuelle Maschinen gemountet wird, um große Datenmengen (Terabyte) dauerhaft zu speichern. Mit fortschreitender Technologie können wir Daten schneller und in viel größeren Mengen aufnehmen. Vor einigen Jahren war es ein einfacher HTTP-Upload einer Datei auf einmal (von relativ kleiner Größe, Megabyte?), dann gingen wir zu Flash-Uploads über. Jetzt haben wir Drag-and-Drop-Uploads, sogar mit der Möglichkeit, in einigen Browsern eine Datei-/Ordnerstruktur im Gigabyte-Bereich hochzuladen. Es kommt zu dem Punkt, an dem ein Benutzer die für /tmp reservierte Partition leicht überschreiten könnte, wenn er wirklich genug auf einmal hochladen möchte. Was wäre der Vorteil einer Erweiterung von /tmp gegenüber der direkten Übermittlung an den Dateiserver, abgesehen von der Netzwerklatenz durch die NFS-Mount? Ist dies eine veraltete (jetzt schlechte) Praxis, die überholt ist, jetzt wo die Technologie es uns ermöglicht, Datenmengen aufzunehmen, die vor einem Jahrzehnt sonst undenkbar gewesen wären?

Answer 1

1. Dient es der Leistung, falls das angegebene Speicherverzeichnis ein Netzwerkspeicher ist?
   • Ja, das kann sein, aber normalerweise nicht. Die Leistung des eigentlichen Uploads ist selten das Hauptproblem hinsichtlich der Leistung des Codes.
2. Durchsucht Linux routinemäßig [sein] /tmp-Verzeichnis, um alte Dateien zu löschen, sodass sich der Entwickler/Administrator nicht anderswo darum kümmern muss?
   • Ja, normalerweise. Dies deckt auch den Fall ab, dass der Upload-Manager-Prozess abstürzt und eine unvollständige Datei hinterlässt, die andernfalls nicht bereinigt werden würde.
3. Ist es einfach so, weil es so ist?
   • Ja. :-)
4. Wenn ich die Möglichkeit habe, die Datei einfach in das Verzeichnis zu schreiben, in dem sie letztendlich gespeichert wird (z. B. mithilfe des fs-Moduls von node.js), sollte ich das tun oder ist das ein No-Go?
   • Es gibt gute Gründe, ein temporäres Staging-Verzeichnis zu verwenden und es im selben Dateisystem wie das Zielverzeichnis zu platzieren. Viele Anwendungen platzieren dieses Verzeichnis im selben Dateibaum wie das endgültige Zielverzeichnis, sodass der endgültige „Verschiebevorgang“ nahezu augenblicklich (und möglicherweise atomar) erfolgt. Daher werden Sie häufig Dinge wie /var/spool/myapp/tmpund sehen /var/spool/myapp/data. Dann fügt die Anwendung jedoch häufig eine cronAufgabe hinzu, um alte Dateien in zu bereinigen .../tmp.

Answer 2

Dies hängt wirklich davon ab, was sich sonst noch auf dem System befindet und wie die Dinge verwendet werden.

Auf einigen Systemen /tmpwird es häufig für Systemdateien oder Swap-Speicher verwendet. Wenn Sie /tmpSolaris vollstopfen,schlimme Dinge passieren(und zugehörige Anekdote). Wenn in einem solchen Fall jemand eine Datei hochlädt, die dieses Volumen füllt, kann Ihr System abstürzen. Außerdem können bestimmte Anwendungen nicht in der Lage sein, ihre eigenen temporären Dateien zu schreiben.

Früher konnte man sich darauf verlassen, dass die Leute nicht dumm waren (zumindest außerhalb des Septembers), und auch die Bosheit war relativ gering. Heute ... ist das eine andere Geschichte.

DerVorteilzum Schreiben /tmpist, dass garantiert wurde, dass es sich um ein lokales Dateisystem auf der Maschine handelt, das vorhanden und überwacht wird (Skripte, die alte Dateien automatisch löschen). Systemeerforderlicha /tmpzum Booten und ein schneller Zugriff darauf war für eine angemessene Leistung des Systems erforderlich. Sie möchten also schnell eine Datei irgendwo schreiben und sie dann verschieben? Legen Sie sie in /tmp.

Angesichts der Tatsache, dass bei /tmpvollem Speicher schlimme Dinge passieren, sollte man sich nach Alternativen umsehen, die dieselben Vorteile bieten – beispielsweise das Erstellen einer Partition, die zum Hochladen von Dateien gemountet ist und die Maschine nicht zum Absturz bringt, wenn der Speicher voll ist.

Eine weitere Überlegung ist jedoch der „schnelle“ Teil. Laufwerke sind seit den alten Tagen schneller geworden. Um einiges schneller – eine gute SSD kann alles von damals in den Schatten stellen … aber wissen SieWirklichBrauchen Sie eine SSD, auf die Sie Upload-Dateien schreiben können? Nicht nur das Tauchen ist schneller geworden, auch das Netzwerk ist schneller geworden. Das Schreiben von Upload-Dateien in einen Netzwerkspeicherbereich kann als einzelner Punkt hilfreich sein, an dem mehrere Systeme ihre Dateien an einen zentralen Ort hochladen können, wo andere Prozesse dann die Aufgabe übernehmen können, sie zu scannen und an den richtigen Ort zu verschieben.

Also... um es zusammenzufassen:

• Hatte in alten Zeiten Vorteile
  • schneller als das Netz, immer da
• Könnte Probleme verursachen
• Die alten Zeiten sind vorbei
  • Laufwerke und Netzwerke schneller
  • Die Leute sind dumm und mehr Angreifer

Daher würde ich als Standardantwort „Nein ... nicht mehr schreiben“ sagen /tmp. Fragen Sie Ihren Systemadministrator nach dem richtigen Ort, an den Sie die Daten schreiben können, der seinen Richtlinien zur Datenträgernutzung entspricht, und ziehen Sie in Erwägung, die Daten an einen Ort außerhalb des lokalen Systems zu schreiben.

Answer 3

/tmpist einfach ein praktischer Ort, um Dateien abzulegen, und zwar irgendwo, wo Sie ziemlich sicher sein können, dass sie bereinigt werden (wenn die Webanwendung dies beispielsweise nicht geschafft hat). Es ist also eine vernünftige Vorgabe.

Wenn Sie die Möglichkeit haben, Ihren eigenen Pfad zum Hochladen der Dateien anzugeben, gibt es einen guten Grund, diesen Pfad auf demselben Mount wie das endgültige Ziel festzulegen, da Sie ihn dann durch eine atomare Umbenennung an seinen endgültigen Platz bringen können. (Bei Cross-Mount müssen Sie eine Kopie erstellen.)

Ich würde es nicht an sein endgültiges Ziel hochladen, da (zum Beispiel) wenn der Upload mittendrin abgebrochen wird, Sie dort mit einer unvollständigen Datei zurückbleiben könnten. Oder wenn Ihr Skript abstürzt, könnten Sie mit einer verwaisten Datei zurückbleiben, auf die Ihre Datenbank nicht verweist.

Übrigens: Denken Sie daran, dass der vom Client bereitgestellte Dateiname nicht vertrauenswürdige Daten enthält. Ein böswilliger Benutzer könnte Ihnen den Dateinamen leicht preisgeben ../../../something, und wenn Sie nicht aufpassen, könnten Sie am Ende etwas in Ihr Programm schreiben, das Sie nicht möchten.