Jaki jest rozmiar zapisu atomowego na dysk w moim systemie?

10

W dokumentacji tej access_logdyrektywy , dokumentacja nginx mówi

Rozmiar bufora nie może przekraczać rozmiaru zapisu atomowego do pliku dyskowego.

Jak mogę ustalić, jaki rozmiar jest w moim systemie?

linux nginx

— bdesham
źródło

@mdpc Z połączonego dokumentu jest całkiem jasne, że nie chodzi o rozmiary sektorów, które btw. było 512 bajtów na większości mediów od końca lat 80. do chwili obecnej. Nastąpił ruch w kierunku wielkości sektorów 4K na nowych dyskach.

— kasperd

Ta specyfikacja może być istotna. Chociaż wydaje się, że nie daje to dokładnej odpowiedzi na pytanie: pubs.opengroup.org/onlinepubs/7908799/xsh/write.html

— kasperd

3

lepiej późno niż wcale :)

szybka odpowiedź brzmi: „2147479552 bajtów, jeśli wersja jądra to 3.14 lub nowsza”

szczegółowa odpowiedź:

O ile rozumiem, chodzi o napisanie syscall:

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

1) gwarantujemy, że wszystkie systemy POSIX (linux, bsd, wszystkie uniksowe) będą mogły zapisać do MAX_SSIZE bajtów

Zgodnie z POSIX.1, jeśli liczba jest większa niż SSIZE_MAX, wynik jest zdefiniowany w implementacji; patrz UWAGI na górny limit w systemie Linux.

# getconf SSIZE_MAX
32767

2) Linux gwarantuje, że będzie mógł napisać do 1,99 GiB (i jest to działanie atomowe dla jądra Linuksa w wersji 3.14 i nowszych)

W systemie Linux write () (i podobne wywołania systemowe) przesyła maksymalnie 0x7ffff000 (2 147 479 552) bajtów, zwracając liczbę faktycznie przesłanych bajtów. (Dotyczy to zarówno systemów 32-bitowych, jak i 64-bitowych.)

Ale to uczciwa operacja atomowa tylko z jądra Linuksa 3.14

Zgodnie z POSIX.1-2008 / SUSv4 sekcja XSI 2.9.7 („Interakcje wątku z normalnymi operacjami na plikach”):

Wszystkie następujące funkcje są atomowe względem siebie w efektach określonych w POSIX.1-2008, gdy działają na zwykłych plikach lub dowiązaniach symbolicznych: ...

Wśród wymienionych poniżej API znajdują się write () i writev (2). A wśród efektów, które powinny być atomowe w wątkach (i procesach), są aktualizacje przesunięcia pliku. Jednak w systemie Linux przed wersją 3.14 tak nie było: jeśli dwa procesy, które współużytkują opis otwartego pliku (patrz open (2)) wykonują jednocześnie write () (lub writev (2)), wówczas I Operacje / O nie były atomowe w odniesieniu do aktualizacji przesunięcia pliku, w wyniku czego bloki danych wyjściowych z dwóch procesów mogą (niepoprawnie) nakładać się. Ten problem został rozwiązany w Linuksie 3.14.

— Oleg Korchagin
źródło

1

Ta odpowiedź Superuser miała dobrą definicję wielkości zapisu atomowego.

Jest to co najmniej tak duży, jak rozmiar sektora sprzętowego, który jest atomowym rozmiarem do odczytu / zapisu.

— mlw4428
źródło

1

OK, więc jak ustalić, jak duży jest sektor dysku?

— bdesham

9

Dokumentacja nginx i odpowiedź administratora nie mówią o tej samej warstwie w stosie pamięci. Dokumentacja nginx mówi o największym zapisie atomowym w warstwie systemu plików, która jest zależna od systemu operacyjnego i FS. Odpowiedź superużytkownika mówi o największym zapisie atomowym na poziomie bloku, który jest zależny od sprzętu.

— kasperd