Qual è la dimensione di una scrittura atomica su disco sul mio sistema?

10

Nella documentazione per la access_logdirettiva , dice la documentazione di nginx

La dimensione del buffer non deve superare la dimensione di una scrittura atomica su un file su disco.

Come posso determinare quale è questa dimensione sul mio sistema?

linux nginx

— bdesham
fonte

@mdpc Dal documento collegato è abbastanza chiaro, che non si tratta di dimensioni del settore, che tra l'altro. sono stati 512 byte sulla maggior parte dei media dalla fine degli anni '80 fino ad ora. C'è un passaggio alle dimensioni del settore 4K sui nuovi dischi.

— Kasperd,

Questa specifica può essere pertinente. Anche se non sembra dare una risposta esatta alla domanda: pubs.opengroup.org/onlinepubs/7908799/xsh/write.html

— kasperd,

3

meglio tardi che mai :)

la risposta rapida è: "2.147.479.552 byte, se la versione del kernel è 3.14 o più recente"

risposta dettagliata:

Per quanto ho capito, si tratta di scrivere syscall:

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

1) qualsiasi sistema POSIX (linux, bsd, all unix) è garantito per poter scrivere fino a MAX_SSIZE byte

Secondo POSIX.1, se count è maggiore di SSIZE_MAX, il risultato è definito dall'implementazione; vedi NOTE per il limite superiore su Linux.

# getconf SSIZE_MAX
32767

2) Linux ha la garanzia di poter scrivere fino a 1,99 GiB (ed è un'operazione atomica per il kernel linux versione 3.14 e successive)

Su Linux, write () (e chiamate di sistema simili) trasferiranno al massimo 0x7ffff000 (2.147.479.552) byte, restituendo il numero di byte effettivamente trasferiti. (Questo è vero su entrambi i sistemi a 32 e 64 bit.)

Ma è un'operazione atomica corretta solo dal kernel linux 3.14

Secondo POSIX.1-2008 / SUSv4 Sezione XSI 2.9.7 ("Interazioni di thread con operazioni regolari sui file"):

Tutte le seguenti funzioni devono essere atomiche l'una rispetto all'altra negli effetti specificati in POSIX.1-2008 quando operano su file regolari o collegamenti simbolici: ...

Tra le API successivamente elencate ci sono write () e writev (2). E tra gli effetti che dovrebbero essere atomici tra i thread (e i processi) ci sono gli aggiornamenti dell'offset del file. Tuttavia, su Linux prima della versione 3.14, questo non era il caso: se due processi che condividono una descrizione di file aperto (vedi open (2)) eseguono un write () (o writev (2)) allo stesso tempo, allora l'I Le operazioni di / O non erano atomiche rispetto all'aggiornamento dell'offset del file, con il risultato che i blocchi di dati emessi dai due processi potevano sovrapporsi (erroneamente). Questo problema è stato risolto in Linux 3.14.

— Oleg Korchagin
fonte

1

Questa risposta di Superuser aveva una buona definizione di quale dimensione di scrittura atomica è.

Questo è almeno grande quanto la dimensione del settore hardware, che è la dimensione atomica di lettura / scrittura.

— mlw4428
fonte

1

OK, quindi come posso determinare quanto è grande un settore del disco?

— bdesham,

9

La documentazione di nginx e la risposta del superutente non parlano dello stesso livello nello stack di archiviazione. La documentazione di nginx parla della più grande scrittura atomica a livello di file system, che dipende dal sistema operativo e da FS. La risposta del superutente parla della più grande scrittura atomica a livello di blocco, che dipende dall'hardware.

— Kasperd,