comprendre la "taille de morceau" dans le context de RAID

Ai-je raison de dire que la taille d'un morceau dans le context du RAID est essentiellement la même chose que le cluster dans le context du système de files? En d'autres termes, la taille de bloc est la plus petite unité de données qui peut être écrite sur un membre de la masortingce RAID? Par exemple, si j'ai une taille de 64KiB et que j'ai besoin d'écrire un file 4KiB et que la taille du cluster du système de files est aussi 4KiB, est-il vrai que j'utiliserai un fragment 64KiB et gaspillera 60KiB?

Étant donné que les morceaux peuvent être assez volumineux et que l'information de parité est simple (c.-à-d. N'affecte pas datatables avant ou après la pièce en question), l'hypothèse selon laquelle seuls des morceaux complets peuvent être écrits n'a pas de sens pour moi.

Les morceaux sont l'unité dans laquelle datatables sont réparties sur les volumes. Un morceau de données continues est écrit sur un certain volume, datatables suivantes sont écrites dans un autre volume.

Avec les filesystems et avec RAID, il s'agit d'un problème d'optimization: dans un système de files, de trop petits blocs / clusters génèrent des métadonnées, les blocs trop gros gaspillent trop d'espace (car la plupart des filesystems ne peuvent utiliser qu'un seul bloc) .

Avec RAID, il est similaire: si vous avez des morceaux minuscules, vous avez besoin d'accéder à plusieurs disques même pour de très petits files (ou d'autres données). Dans la plupart des cas, la latence plus élevée du lecteur (dans ce cas) plus lent prend plus de time que la lecture d'un seul lecteur. Ceci n'est pas valable pour les disques SSD, mais ils ne sont pas la technologie dominante pour RAID.

Si vous avez de très gros morceaux, alors même les access qui pourraient être clairement accélérés par la propagation à plusieurs lecteurs sont effectués sur un seul lecteur.