Який розмір атомного запису на диск моєї системи?

10

У документації до access_logдирективи йдеться про документацію nginx

Розмір буфера не повинен перевищувати розмір атомного запису на файл диска.

Як я можу визначити, що таке розмір у моїй системі?

linux nginx

@mdpc З пов'язаного документа досить зрозуміло, що мова йде не про розміри сектору, які btw. У більшості медіа з кінця 80-х до цього часу було 512 байт. На нових накопичувачах спостерігається перехід до розмірів сектору 4K.

— kasperd

Ця специфікація може бути актуальною. Хоча, схоже, не дається точної відповіді на питання: pubs.opengroup.org/onlinepubs/7908799/xsh/write.html

— kasperd

3

краще пізно, ніж ніколи :)

швидка відповідь: "2,147,479,552 байт, якщо версія ядра 3,14 або новіша"

детальна відповідь:

Наскільки я розумію, мова йде про написання syscall:

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

1) будь-які POSIX системи (linux, bsd, всі unix) гарантовано зможуть записувати до MAX_SSIZE байт

Відповідно до POSIX.1, якщо кількість перевищує SSIZE_MAX, результат визначається реалізацією; див. ПРИМІТКИ щодо верхньої межі для Linux.

# getconf SSIZE_MAX
32767

2) Linux гарантував можливість запису до 1,99 ГБ (і це атомна операція для ядра Linux версії 3.14 і новішої)

В Linux, функція write () (і подібні системні виклики) передасть не більше 0x7ffff000 (2,147,479,552) байт, повертаючи кількість фактично переданих байтів. (Це справедливо як для 32-бітної, так і для 64-бітної систем.)

Але це справедлива атомна операція лише з ядра Linux 3.14

Відповідно до POSIX.1-2008 / SUSv4 розділу XSI 2.9.7 ("Взаємодія ниток з регулярними операціями з файлами"):

Усі наступні функції повинні бути атомними відносно один одного в ефектах, зазначених у POSIX.1-2008, коли вони працюють на звичайних файлах або символічних посиланнях: ...

Серед згодом перелічених API - записи () та writev (2). І серед ефектів, які мають бути атомними в потоках (і процесах), є оновлення зміщення файлу. Однак в Linux до версії 3.14 цього не було: якщо два процеси, які мають спільний опис відкритого файлу (див. Відкритий (2)), виконують запис () (або writev (2)) одночасно, то I Операції / виведення не були атомними щодо оновлення зміщення файлу, внаслідок чого блоки виведення даних двома процесами можуть (неправильно) перетинатися. Ця проблема була виправлена в Linux 3.14.

— Олег Корчагін
джерело

1

Ця відповідь Суперусера мала хороше визначення того, що таке розмір атомного запису.

Це принаймні настільки ж велике, як розмір апаратного сектора, який є атомним читанням / записом.

— mlw4428
джерело

1

Гаразд, тож як я можу визначити, наскільки великий диск-сектор?

— бдешам

9

Документація nginx та відповідь суперпользователя не говорять про один і той же рівень у стеці зберігання. Документація nginx говорить про найбільшу атомну запис на рівні файлової системи, від якої залежать ОС і FS. Відповідь суперпользователя говорить про найбільший атомний запис на рівні блоку, який залежить від обладнання.

— kasperd