Quelle est la taille d'une écriture atomique sur disque sur mon système?

10

Dans la documentation de la access_logdirective , la documentation nginx indique

La taille du tampon ne doit pas dépasser la taille d'une écriture atomique dans un fichier disque.

Comment puis-je déterminer quelle est cette taille sur mon système?

linux nginx

— bdesham
source

@mdpc D'après le document lié, il est assez clair qu'il ne s'agit pas de tailles de secteur, qui d'ailleurs. a été de 512 octets sur la plupart des médias depuis la fin des années 80 jusqu'à maintenant. Il y a une évolution vers des tailles de secteur 4K sur les nouveaux disques.

— kasperd

Cette spécification peut être pertinente. Bien qu'il ne semble pas donner de réponse exacte à la question: pubs.opengroup.org/onlinepubs/7908799/xsh/write.html

— kasperd

3

Mieux vaut tard que jamais :)

la réponse rapide est: "2 147 479 552 octets, si la version du noyau est 3,14 ou plus récente"

réponse détaillée:

Pour autant que je comprends, il s'agit d'écrire syscall:

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

1) tous les systèmes POSIX (linux, bsd, tout unix) sont garantis pour pouvoir écrire jusqu'à MAX_SSIZE octets

Selon POSIX.1, si le nombre est supérieur à SSIZE_MAX, le résultat est défini par l'implémentation; voir NOTES pour la limite supérieure sous Linux.

# getconf SSIZE_MAX
32767

2) Linux est garanti pour pouvoir écrire jusqu'à 1,99 Gio (et c'est une opération atomique pour le noyau Linux version 3.14 et plus récente)

Sous Linux, write () (et les appels système similaires) transfèrent au plus 0x7ffff000 (2 147 479 552) octets, renvoyant le nombre d'octets réellement transférés. (Cela est vrai sur les systèmes 32 bits et 64 bits.)

Mais c'est un fonctionnement atomique équitable uniquement à partir du noyau Linux 3.14

Selon POSIX.1-2008 / SUSv4, section XSI 2.9.7 («Interactions de thread avec des opérations de fichiers régulières»):

Toutes les fonctions suivantes doivent être atomiques les unes par rapport aux autres dans les effets spécifiés dans POSIX.1-2008 lorsqu'elles fonctionnent sur des fichiers normaux ou des liens symboliques: ...

Parmi les API répertoriées par la suite figurent write () et writev (2). Et parmi les effets qui devraient être atomiques entre les threads (et les processus), il y a les mises à jour du décalage de fichier. Cependant, sous Linux avant la version 3.14, ce n'était pas le cas: si deux processus qui partagent une description de fichier ouvert (voir open (2)) effectuent une écriture () (ou writev (2)) en même temps, alors le I Les opérations d'E / S n'étaient pas atomiques en ce qui concerne la mise à jour de l'offset de fichier, avec pour résultat que les blocs de données sortis par les deux processus pourraient (incorrectement) se chevaucher. Ce problème a été corrigé dans Linux 3.14.

— Oleg Korchagin
source

1

Cette réponse de superutilisateur avait une bonne définition de la taille d'écriture atomique.

C'est au moins aussi grand que la taille du secteur matériel, qui est la taille atomique en lecture / écriture.

— mlw4428
source

1

OK, alors comment déterminer la taille d'un secteur de disque?

— bdesham

9

La documentation nginx et la réponse du superutilisateur ne parlent pas de la même couche dans la pile de stockage. La documentation nginx parle de la plus grande écriture atomique au niveau de la couche du système de fichiers, qui dépend du système d'exploitation et de FS. La réponse du superutilisateur parle de la plus grande écriture atomique au niveau du bloc, qui dépend du matériel.

— kasperd