Quelle est la relation entre la taille du bloc et l'IO ?

Je pense que le Article de Wikipedia l'explique assez bien :

Absence de spécifications simultanées du temps de réponse et de la charge de travail, Les IOPS sont essentiellement sans signification.
...
Tout comme les repères, les chiffres d'IOPS publiés par les fabricants de périphériques de stockage ne sont pas directement liés aux performances des applications du monde réel. ...

Maintenant, à vos questions :

Qui décide donc de la taille de la demande d'OI ?

Il est à la fois facile et difficile de répondre à cette question pour un non-programmeur comme moi.

Comme d'habitude, la réponse est un insatisfaisant " cela dépend "...

Les opérations d'E/S concernant le stockage sur disque par une application sont généralement des appels système au système d'exploitation et leur taille dépend de l'appel système effectué...

Je suis plus familier avec Linux qu'avec les autres systèmes d'exploitation, je vais donc m'en servir comme référence.

La taille des opérations d'E/S telles que open() , stat() , chmod() et similaires est presque négligeable.
Sur un disque en rotation, les performances de ces appels dépendent principalement de la quantité d'énergie nécessaire à l'actionneur du disque pour déplacer le bras et la tête de lecture dans la bonne position sur le plateau du disque.

D'autre part, la taille d'un read() y write() est initialement fixé par l'application et peut varier entre 0 y 0x7ffff000 (2 147 479 552) octets dans une seule requête d'E/S...

Bien entendu, une fois qu'un tel appel système a été effectué par l'application et qu'il est reçu par le système d'exploitation, l'appel sera traité comme suit planifié et mis en file d'attente (selon que l'indicateur O_DIRECT a été utilisé ou non pour contourner le cache de page et les tampons et que l'entrée/sortie directe a été sélectionnée).

L'appel système abstrait devra être mis en correspondance avec les opérations sur le système de fichiers sous-jacent, qui est ordonné de manière discrète. blocs (dont la taille est généralement définie lors de la création du système de fichiers) et, éventuellement, le pilote de disque opère sur l'un ou l'autre des éléments suivants secteurs du disque dur de 512 ou 4096 octets ou des pages de mémoire SSD de 2K, 4K, 8K ou 16K.

(Pour les benchmarks, les appels de lecture et d'écriture sont généralement fixés à 512B ou 4KB, ce qui s'aligne très bien avec le disque sous-jacent et permet d'obtenir des performances optimales).

Il doit y avoir une limite au-delà de laquelle la demande se divise en plusieurs IO. Comment trouver cette limite ?

Oui, il y a une limite, sous Linux, comme indiqué dans le manuel, une seule read() o write() L'appel système renverra un maximum de 0x7ffff000 (2,147,479,552) octets. Pour lire des fichiers plus volumineux, vous aurez besoin d'appels système supplémentaires.

La lecture de chaque bloc signifie-t-elle une seule entrée/sortie ?

D'après ce que je comprends, chaque occurrence d'un appel système est considérée comme un événement IO.

Un seul read() L'appel système compte comme 1 événement I/0 et non comme X ou Y IO's, quelle que soit la façon dont cet appel système est traduit/implémenté pour accéder à X blocs d'un système de fichiers ou lire Y secteurs d'un disque dur en rotation.

On dirait que vous essayez de décoder cette déclaration :

"Moins d'IOPS seront effectués si vous avez une taille de bloc plus grande pour votre système de fichiers".

Je vais essayer de reformuler cette déclaration pour rendre le sens de l'auteur original plus clair :

"Pour lire un fichier d'une taille donnée (10 Mo, par exemple), un système de fichiers formaté avec une taille de bloc plus importante devra probablement doivent effectuer un nombre inférieur d'opérations de lecture qu'un système de fichiers formaté avec une taille de bloc plus petite."

J'espère que ma reformulation a un peu plus de sens que l'original.

Pour analyser correctement cette déclaration et comprendre la raison de a) l'utilisation du terme "système de fichiers" au lieu de disque et b) ce "probablement", vous devrez en apprendre beaucoup plus sur toutes les couches logicielles entre les données sur un disque (ou SSD) et les applications utilisateur. Je peux vous donner quelques indications pour commencer à chercher sur Google :

Pour les disques rotatifs :

• Taille du secteur (disque) et taille du bloc (système de fichiers)

Découvrez la mise en cache :

• Cache de page/buffer dans le noyau du système d'exploitation

• Mise en cache des E/S dans les bibliothèques de niveau utilisateur (dont les plus importantes sont libc et libc++).

Pour les SSD ou tout autre type de stockage flash, il existe des complications supplémentaires. Vous devriez vous renseigner sur le fonctionnement du stockage flash en unités de pages et sur la raison pour laquelle tout stockage flash nécessite un processus de collecte des déchets.