Linux atomarer Dateizugriff

move ist üblicherweisse atomar. Man schreibt in eine temporäre Datei und 
movet dann an den eigentlichen Zielort.

Oh, dafür liebe ich dieses Forum! funktioniert das auch, wenn am Zielort 
zuvor eine Datei mit gleichem Namen ist, die ersetzt wird? Weil die 
Internetseite ja immer auf den gleichen Dateinamen zugreift.
Danke!

Ja, das ist echt nett von Linux! Aber auch von euch für die schnelle 
Hilfe! Danke nochmals!

Kai S. schrieb:
> The rename() system call guarantees that an instance of new will always
>      exist, even if the system should crash in the middle of the
> operation.
>
> Nett, oder ?

nein, denn es garantiert nur das die Datei immer Vorhanden ist. Entweder 
über den neuen oder den alten Namen.

Es garantiert nicht, das die Zieldatei immer verfügbar ist. Das das 
Problem bekannt ist, wurde im einer der letzter Kernel Version eine 
neuer Syscall eingebaut, der 2 Dateien atomar tauscht.

@Freiherr Isidor von Dornheim
Es sind nicht sehr sinnvoll ständig auf der Festplatte rumzuschreiben, 
dafür sie die SD-Karten nicht gedacht.

Ich würde das Image einfach im Ram speichern, für Webserver bietet sich 
z.b. memcache an.

Und wie schreibe ich eine Datei in den Ram? Ist memcache ein Mountpoint, 
über den das RAM im Dateisystem zugängig ist? Eigentlich wollte ich alle 
Bilder auch archivieren. Dafür müsste ich ohnehin auf die SD-Karte (oder 
ein USB-Medium) schreiben.

Freiherr Isidor von Dornheim-Rottenburg schrieb:
> Und wie schreibe ich eine Datei in den Ram? Ist memcache ein Mountpoint,
> über den das RAM im Dateisystem zugängig ist? Eigentlich wollte ich alle
> Bilder auch archivieren. Dafür müsste ich ohnehin auf die SD-Karte (oder
> ein USB-Medium) schreiben.

memcache ist keine Ramdisk sondern ein Programm.

http://de.wikipedia.org/wiki/Memcached

> Eigentlich wollte ich alle
> Bilder auch archivieren. Dafür müsste ich ohnehin auf die SD-Karte (oder
> ein USB-Medium) schreiben.
davon war aber vorher keine rede.

oft werden Dateien unter unix auch mit Namen ".name" geschrieben 
(unsichtbare Datei) und wenn sie fertig geschrieben sind nach "name" via 
mv verschoben ...

Praktiker schrieb:
> oft werden Dateien unter unix auch mit Namen ".name" geschrieben
> (unsichtbare Datei) und wenn sie fertig geschrieben sind nach "name" via
> mv verschoben ...

und schon haben wir wieder das atomar Problem.

Peter II schrieb:
> und schon haben wir wieder das atomar Problem.

Nein.

@Peter II: Ok, aber eine Ramdisk könnte mir auch helfen um zu 
verhindern, dass die SD-Karte so schnell "abgenutzt" wird. Dort könnte 
ich immer das aktuelle Foto ablegen. Zum Archivieren könnte ich auf ein 
externes Laufwerk (usb-Festplatte) ausweichen.
Dass ich das mit dem Archivieren zuerst nicht geschrieben habe, war weil 
ich nicht dachte, dass das relevant für mein Problem wäre, Sorry

Gruß
Freiherr Isidor von Dornheim-Rottenburg

Ihr Vollpfosten solltet mal nachlesen was "atomar" bedeutet.
Bei Speichermedien mit FS ist gar kein Zugriff atomar.

Man kann höchstens die Zeitspanne verkürzen, in der die
Bilddatei geschrieben wird, in der Hoffnung, dass es
dann seltener vorkommt, dass der Webserver während
der Speicherung das Bild lädt und darstellt.
Scheinbar ist das Programm, welches das Bild macht und
abspeichert, langsamer als move.

Gustav schrieb:
> Peter II schrieb:
>> und schon haben wir wieder das atomar Problem.
>
> Nein.

doch. Die Datei wird kurzzeitig nicht verfügbar sein.

wenn du alle Bilder aufheben willst, kannst du sie unter einem 
eindeutigen Namen (2014-08-22-1050 oder so) auf die SD-Karte schreiben 
und dann die gerade geschriebene Datei nach /tmp kopieren. Anschließend 
wird sie mit mv umbenannt, damit der Name für den Webserver immer gleich 
bleibt.

Auf die Art wird genau so viel wie nötig und so wenig wie möglich auf 
die SD-Karte geschrieben. Für /tmp verwendet man heutzutage "tmpfs"; 
normal sollte das sowieso so eingerichtet sein.

Peter II schrieb:
> Gustav schrieb:
>> Peter II schrieb:
>>> und schon haben wir wieder das atomar Problem.
>>
>> Nein.
>
> doch. Die Datei wird kurzzeitig nicht verfügbar sein.

Nein.

1

Foto.jpeg ---> altes_bild

2

3

Foto.jpeg ---> altes_bild

4

201408221050 ---> halbes_neues_bild

5

6

Foto.jpeg ---> altes_bild

7

201408221050 ---> neues_bild

8

9

mv 201408221050 Foto.jpeg

10

11

Foto.jpeg ---> neues_bild

oder wie sonst läuft das ab?

liegt /tmp dann auf dem ram? Oder auf der SD-Karte? Andernfalls könnte 
ich das auch mit einer RAMdisk realisieren

Schaulus Tiger schrieb:
> mv 201408221050 Foto.jpeg

das ist das Problem.

Wenn im Hintergrund ein Programm ständig auf Foto.jpeg zugreifst, wirst 
du merken das es kurzeitig nicht das ist.

Du bekommst du Datei für einen kurzen Moment nicht geöffnet, weil sie 
nicht da ist.

Für eine Webcam mag das ok sein, sauber ist es so auf jeden fall nicht.

so hier noch das Problem:

http://www.heise.de/open/artikel/Kernel-Log-Was-3-15-bringt-1-Dateisysteme-und-Storage-2183256.html

Atomar umbenennen

Über den neuen Syscall "renameat2()" kann Software den Kernel anweisen, 
zwei Dateien atomar auszutauschen. Userspace-Programme sehen so entweder 
den alten oder neuen Zustand, nie aber einen der Zustände im 
Umbenennungsprozess. Das ist unter anderem zur sauberen Implementierung 
von Dateisystemen wichtig, die per "Union Mounting" mehrere Dateisysteme 
zu einem verbinden; das nutzen beispielsweise Live-Linuxe, um den Inhalt 
einer schreibgeschützten DVD mit dem Inhalt eines beschreibbaren 
USB-Sticks zu einem einzelnen Dateisystem zu verknüpfen, das alle neu 
geschriebenen Daten auf dem USB-Stick ablegt. Der neue Syscall ist damit 
ein wichtiger Schritt zur Union-Mount-Unterstützung im Kernel, auf die 
wechselnde Entwickler seit über fünfzehn Jahren hinarbeiten.

Klaus Wachtler schrieb:
> Damit das wiederum nicht kollidiert, könnte man jeweils den neuen Link
> mit einem temprären Namen anlegen (z.B. in einem tmpfs-Verzeichnis) und
> anschließend in den richtigen Namen umbenennen.

und das ist schon wieder nicht Atomar. Beim umbenennen gibt es 
kurzzeitig da Ziel nicht mehr.

>Es sind nicht sehr sinnvoll ständig auf der Festplatte rumzuschreiben,
>dafür sie die SD-Karten nicht gedacht.

Cronjobs habe normalerweise in minimale Auflösung von 1 Minute.
Das wird für die SD-Karten wohl nicht so kritisch sein??!
Das System schreibt sowieso viel auf der SD-Platte "rum".

Ein mv(1) auf dem selben Dateisystem bzw. rename(2) ist unter Linux und 
jedem anständigen Unix atomar und garantiert auch, dass die Datei zu 
jedem Zeitpunkt mit open(2) geöffnet werden kann.

Thorsten schrieb:
> Ein mv(1) auf dem selben Dateisystem bzw. rename(2) ist unter Linux und
> jedem anständigen Unix atomar und garantiert auch, dass die Datei zu
> jedem Zeitpunkt mit open(2) geöffnet werden kann.

wo steht das genau?

wenn ich Datei X nach Y umbenenne, dann heist das das X immer lesbar 
ist, zu Y erfolgt keine Aussage.

Wir haben zumindest und Linux das Problem gehabt, das beim umbenennen 
genau zu diesen Problem kommt.

Nürnberger schrieb:
> Cronjobs habe normalerweise in minimale Auflösung von 1 Minute.
> Das wird für die SD-Karten wohl nicht so kritisch sein??!
> Das System schreibt sowieso viel auf der SD-Platte "rum".

warum sollte es da tun? Festplatten schaltet sich sogar bei einem 
timeout von 10min ab, weil nichts zu schreiben ist.

Peter II schrieb:
> Wenn im Hintergrund ein Programm ständig auf Foto.jpeg zugreifst, wirst
> du merken das es kurzeitig nicht das ist.

Das kannst du noch so oft behaupten, es wird dadurch aber nicht richtig.

Gustav schrieb:
> Das kannst du noch so oft behaupten, es wird dadurch aber nicht richtig.

und warum wird dann extra eine neue Kernel Funktion geschrieben?

http://lwn.net/Articles/569134/

Gustav schrieb:
> Das kannst du noch so oft behaupten, es wird dadurch aber nicht richtig.

ok geben micht geschlagen:

http://man7.org/linux/man-pages/man2/rename.2.html
 If newpath already exists, it will be atomically replaced (subject to
       a few conditions; see ERRORS below), so that there is no point at
       which another process attempting to access newpath will find it
       missing.

aber wir hatte zumindest Probleme damit, er verlasse mich nicht darauf.

Peter II schrieb:
> wenn ich Datei X nach Y umbenenne, dann heist das das X immer lesbar
> ist, zu Y erfolgt keine Aussage.

Bei einem
  rename("old", "new");
bei existentem "new" ist garantiert dass "new" während des Umbennenens 
immer existiert und gelesen werden kann. Ohne diese Semantik würden 
etliche Programme nicht korrekt funktionieren.

Nachlesen kann man das unter anderem in POSIX 1998. Zitat:

If the link named by the new argument exists, it shall be removed and 
old renamed to new. In this case, a link named new shall remain visible 
to other processes throughout the renaming operation and refer either to 
the file referred to by new or old before the operation began.

Peter II schrieb:
> Nürnberger schrieb:
>> Cronjobs habe normalerweise in minimale Auflösung von 1 Minute.
>> Das wird für die SD-Karten wohl nicht so kritisch sein??!
>> Das System schreibt sowieso viel auf der SD-Platte "rum".
>
> warum sollte es da tun? Festplatten schaltet sich sogar bei einem
> timeout von 10min ab, weil nichts zu schreiben ist.

Naja, ein aktiver webserver loggt ja alles mögliche.
(ok, das könnte man sicherlich deaktivieren)
Üblicherweise wird für log-Daten kein tmp-Verzeichnis gewählt,
denn dann wären diesen Daten nach einem System-Absturz weg.

bevor du eine neue datei schreibst löschst du die alte (mit dem selben 
namen). falls die alte grade geöffnet war kann das programm immernoch 
den inhalt lesen (und reinschreiben). eine alte unix hacktechnik um 
unsichtbar daten wegschreiben zu können - die datei taucht als name im 
FS nicht auf, aber das handle ist noch geöffnet und es kann ganz normal 
darauf zugegriffen werden.

für den fall das deine websoftware genau dann ein bild laden will wenn 
die alte datei eben gelöscht, aber nie neue noch nicht angelegt wurde, 
machst du zwei zugriffe mit einem timeout(<erstellungsintervall) 
dazwischen.


es gibt übrigens noch die möglichkeit video direkt zu streamen (weiß 
aber nicht ob der raspi das eventuelle transcoden schafft) - falls du es 
ganz hardcore haben willst ;)

Freiherr Isidor von Dornheim-Rottenburg schrieb:
> @Peter II: Ok, aber eine Ramdisk könnte mir auch helfen um zu
> verhindern, dass die SD-Karte so schnell "abgenutzt" wird.

Vergiss das mit der schnellen Abnutzung.

Ich habe hier einen 32GB USB Stick (Sandisk Cruzer Blade), auf den 
werden täglich (24/7/365) 12960 jpgs von 5 Kameras geschrieben, ca. 
50..100kB pro jpg je nach cam.

Zusätzlich noch 1x täglich je ein Zeitraffervideo von 50...175MB pro 
cam.

Auslastung des Sticks schwankt zwischen 50%...80%, d.h. ich habe immer 
mindestens 20% des Speicherplatzes frei.

Der Stick ist seit mehr als einem Jahr im Einsatz, ohne 
Ausfallerscheinungen.

Wenn USB Sticks kaputtgehen, dann nicht durch "Abnutzung" durch häufiges 
Schreiben, sondern durch mechanische Belastung.

Schaulus Tiger schrieb:
> Foto.jpeg ---> altes_bild
>
> Foto.jpeg ---> altes_bild
> 201408221050 ---> halbes_neues_bild
>
> Foto.jpeg ---> altes_bild
> 201408221050 ---> neues_bild
>
> mv 201408221050 Foto.jpeg
>
> Foto.jpeg ---> neues_bild

Exakt so mache ich das auch (anderer Rechner als der vorhin beschriebene 
mit 5 cams) und konnte bisher keine "kurzfristige" Nicht-Verfügbarkeit 
feststellen.

Für den angedachten Anwendungszweck funktioniert das hervorragend.

Und btw: Kann bitte mal jemand das schon so oft genannte "kurzfristig" 
näher quantifizieren? Ich behaupte, das "kurzfristig" ist so kurz, daß 
es keine praktische Relevanz hat.

tmomas schrieb:
> Vergiss das mit der schnellen Abnutzung.

ich habe schon 2 stick mit 2GB damit geschrotet. Hatte ein normales 
Linux drauf und /var nicht auf ein tmpfs gelegt.

Nach jeweils 1Jahr hatte der Stick Schreibfehler.

Peter II schrieb:
> und warum wird dann extra eine neue Kernel Funktion geschrieben?

Weil ein atomic swap etwas anderes ist. Da wird dir auch über die Datei 
"old" eine Garantie gegeben.

Peter II schrieb:
> aber wir hatte zumindest Probleme damit, er verlasse mich nicht darauf.

Bei MacOS X ist das angeblich kaputt, weil nicht-atomar.

Peter II schrieb:
> tmomas schrieb:
>> Vergiss das mit der schnellen Abnutzung.
>
> ich habe schon 2 stick mit 2GB damit geschrotet. Hatte ein normales
> Linux drauf und /var nicht auf ein tmpfs gelegt.
>
> Nach jeweils 1Jahr hatte der Stick Schreibfehler.

Welche Marke?
Wieviele Dateien bzw. MB/Tag hast du draufgeschrieben?


- Nimm einen Markenstick (Sandisk Cruzer Blade / Sandisk Cruzer fit sind 
meine Lieblinge)
- Nimm einen "großen" Stick. 8 oder 16GB kosten ja heute nichts mehr.
- Sorge dafür, daß immer ca. 20% frei sind. Betonung auf immer.
- Die jpgs und videos werden bei mir regelmäßig gelöscht, d.h. alle 
Speicherzellen werden mehr oder weniger gleichmäßig belastet. Es gibt 
nicht die Situation, daß von den 32GB 30GB dauerhaft belegt sind, und 
nur auf den restlichen 2GB rumgeschrieben wird.

Anmerkung: /var liegt bei mir auf einem tmpfs.

tmomas schrieb:
> Und btw: Kann bitte mal jemand das schon so oft genannte "kurzfristig"
> näher quantifizieren? Ich behaupte, das "kurzfristig" ist so kurz, daß
> es keine praktische Relevanz hat.

Null, jedenfalls in diesem Anwendungsfall mit "mv"; ich glaube, soweit 
waren wir uns inzwischen einig.

Man kann natürlich gemein sein: Das "mv" braucht eine gewisse 
Ausführungszeit, gerade auf SD-Karten (im Extremfall wohl über 1 
Sekunde). Und gerade weil es atomar ist, ist während der Zeit kein 
Zugriff möglich. Es gibt zwar keinen Fehler oder falsche Daten, aber 
wenn diese Verzögerung stört...

Guten Morgen,
danke für eure Hilfe in dieser Sache. Hier kamen wirklich von allen 
Seiten sehr konstruktive Beiträge!

 @Andy D. : Ja, das finde ich ziemlich gut. Mir ist es wichtig, dass zu 
JEDER Zeit ein vollständiges, nicht korrumpiertes Foto zur Verfügung 
steht. Auch wenn gerade ein neues aufgenommen/abgespeichert wird.

@all:
Der Raspberry-Webcamserver soll über eine Dyn-DNS im Netz hängen. Ich 
möchte aber nicht, dass jeder Besucher meiner Seite gleich "zu mir nach 
Hause gehen kann" - ich möchte die Dyndns nicht im für Seitenbesucher 
sichtbaren Seitenquelltext stehen haben. Gibt es eine Möglichkeit, den 
Hauptwebserver mit php dazu zu bringen (regelmäßig) das neueste Foto vom 
Webcamwebserver zu holen und dann aus einem eigenen Verzeichnis zum 
Seitenbesucher zu bringen?

Ich hoffe ich konnte verständlich machen, was ich möchte. Wenn nicht, 
einfach nochmal nachhaken ;)

Vielen Dank schon mal im Voraus!

Freiherr Isidor von Dornheim-Rottenburg

OK danke,
ich denke ich werde es wohl bei Seitenaufruf machen müssen, weil ich bei 
dem Hauptwebserver nur ftp-Zugriff und einen (eingeschränkten) 
Datenbank-Zugang habe. Ich kann also keinen Cron-Job installieren. Oder 
kann man das auch auf eine andere Art und Weise regelmäßig laufen 
lassen? Ich habe mit php leider noch keine Erfahrungen gemacht.

Freiherr Isidor von Dornheim-Rottenburg schrieb:
> Gibt es eine Möglichkeit, den
> Hauptwebserver mit php dazu zu bringen (regelmäßig) das neueste Foto vom
> Webcamwebserver zu holen und dann aus einem eigenen Verzeichnis zum
> Seitenbesucher zu bringen?

Wie schon erwähnt: cronjob + curl oder auch ein einfaches wget

Alternativ: Laß doch den Raspi das neue Bild auf den Hauptserver 
hochladen. Auf dem hast du doch alle Möglichkeiten, oder zumindest mehr 
Möglichkeiten, als auf dem Hauptserver, oder?

Ja, auf dem Raspberry habe ich freie Hand. Ich kann also das Foto von da 
aus per ftp zum Webserver befördern. Dann stellt sich aber erneut die 
Frage, ob ich das jeweils aktuelle Foto zum Webserver laden kann (und 
dabei das vorherige überschreiben) und dabei zu JEDER Zeit ein nicht 
korrumpiertes Foto an den Website-Besucher ausliefern kann?

Freiherr Isidor von Dornheim-Rottenburg schrieb:
> Oer wie würdet ihr das Problem lösen?

Mit einer Lockdatei in dem Verzeichnis, in dem die Bilder liegen. Das 
ist dann "so eine Art Mutex", wie Du Dir das wünschst.

Ich habe den Thread jetzt nur überflogen, aber ich glaube, dass das noch 
nicht vorgeschlagen wurde - was mich wundert :-)