Wie groß ist ein atomares Schreiben auf die Festplatte auf meinem System?

10

In der Dokumentation für die access_logRichtlinie , sagt die nginx Dokumentation

Die Puffergröße darf die Größe eines atomaren Schreibvorgangs in eine Festplattendatei nicht überschreiten.

Wie kann ich feststellen, wie groß diese Größe auf meinem System ist?

linux nginx

— bdesham
quelle

@mdpc Aus dem verknüpften Dokument geht ziemlich klar hervor, dass es nicht um Sektorgrößen geht, die übrigens. hat seit den späten 80ern bis jetzt 512 Bytes auf den meisten Medien. Bei neuen Laufwerken gibt es eine Tendenz zu 4K-Sektorgrößen.

— Kasperd

Diese Spezifikation kann relevant sein. Obwohl es keine genaue Antwort auf die Frage zu geben scheint: pubs.opengroup.org/onlinepubs/7908799/xsh/write.html

— kasperd

3

besser spät als nie :)

Die schnelle Antwort lautet: "2.147.479.552 Byte, wenn die Kernel-Version 3.14 oder neuer ist."

ausführliche Antwort:

Soweit ich weiß, geht es darum, syscall zu schreiben:

http://man7.org/linux/man-pages/man2/write.2.html

1) Alle POSIX-Systeme (Linux, BSD, alle Unix) können garantiert bis zu MAX_SSIZE-Bytes schreiben

Laut POSIX.1 ist das Ergebnis implementierungsdefiniert, wenn die Anzahl größer als SSIZE_MAX ist. Siehe NOTES für die Obergrenze unter Linux.

# getconf SSIZE_MAX
32767

2) Linux kann garantiert bis zu 1,99 GiB schreiben (und es ist eine atomare Operation für Linux-Kernel Version 3.14 und neuer).

Unter Linux überträgt write () (und ähnliche Systemaufrufe) höchstens 0x7ffff000 (2.147.479.552) Bytes und gibt die Anzahl der tatsächlich übertragenen Bytes zurück. (Dies gilt sowohl für 32-Bit- als auch für 64-Bit-Systeme.)

Aber es ist faire atomare Operation nur von Linux-Kernel 3.14

Gemäß POSIX.1-2008 / SUSv4 Abschnitt XSI 2.9.7 ("Thread-Interaktionen mit regulären Dateivorgängen"):

Alle folgenden Funktionen müssen in den in POSIX.1-2008 angegebenen Effekten zueinander atomar sein, wenn sie mit regulären Dateien oder symbolischen Links arbeiten: ...

Zu den nachfolgend aufgeführten APIs gehören write () und writev (2). Zu den Effekten, die über Threads (und Prozesse) hinweg atomar sein sollten, gehören Aktualisierungen des Dateiversatzes. Unter Linux vor Version 3.14 war dies jedoch nicht der Fall: Wenn zwei Prozesse, die eine offene Dateibeschreibung gemeinsam haben (siehe open (2)), gleichzeitig ein write () (oder writev (2)) ausführen, wird das I. / O-Operationen waren in Bezug auf die Aktualisierung des Dateiversatzes nicht atomar, mit dem Ergebnis, dass sich die von den beiden Prozessen ausgegebenen Datenblöcke (fälschlicherweise) überlappen könnten. Dieses Problem wurde in Linux 3.14 behoben.

— Oleg Korchagin
quelle

1

Diese Superuser-Antwort hatte eine gute Definition der atomaren Schreibgröße.

Dies ist mindestens so groß wie die Größe des Hardwaresektors, dh die atomare Lese- / Schreibgröße.

— mlw4428
quelle

1

OK, wie bestimme ich, wie groß ein Festplattensektor ist?

— Bdesham

9

In der Nginx-Dokumentation und in der Superuser-Antwort wird nicht über dieselbe Ebene im Speicherstapel gesprochen. In der Nginx-Dokumentation wird über das größte atomare Schreiben auf der Dateisystemebene gesprochen, das vom Betriebssystem und vom FS abhängig ist. Die Superuser-Antwort spricht vom größten atomaren Schreibvorgang auf Blockebene, der hardwareabhängig ist.

— Kasperd