Comment trouver la taille de lecture des blocs matériels de mon disque dur ?

En lsblk est très utile à cet égard :

lsblk -o NAME,PHY-SeC

Les résultats :

NAME   PHY-SEC 
sda        512 
sda1     512 
sda2     512 
sda5     512

Linux indique la taille physique des secteurs dans les fichiers /sys/block/sdX/queue/physical_block_size . Cependant, pour obtenir les meilleures performances, vous devriez probablement faire quelques essais avec différentes tailles et mesures. Je pourrais pas trouver a clair Antwort dans la mesure où l'utilisation de la taille exacte du bloc physique permettrait d'obtenir un résultat optimal (même si je suppose qu'il ne peut s'agir d'un mauvais choix).

$ sudo hdparm -I /dev/sda | grep -i physical
Physical Sector size:                  4096 bytes

http://wayback.archive.org/web/20150921015457/https://nxadm.wordpress.com/2010/04/30/4096-physical-block-size-drives/

La mienne ne prétend pas être une réponse complète, mais j'espère qu'elle sera utile.

Voici un petit extrait de http://mark.koli.ch/2009/05/howto-whole-disk-backups-with-dd-gzip-and-p7zip.html

3 - Déterminer la taille appropriée des blocs

Pour une sauvegarde plus rapide, il peut être utile de déterminer la taille optimale des blocs du disque que vous allez sauvegarder. En supposant que vous allez sauvegarder /dev/sda, voici comment vous pouvez utiliser la commande fdisk pour déterminer la meilleure taille de bloc :

rescuecd#/> /sbin/fdisk -l /dev/sda | grep Units

Units = cylinders of 16065 * 512 = 8225280 bytes

Notez que la sortie du fdisk indique "cylindres de 16065 * 512". Cela signifie qu'il y a 512 octets par bloc sur le disque. Vous pouvez améliorer considérablement la vitesse de la sauvegarde en augmentant la taille des blocs d'un multiple de 2 à 4. Dans ce cas, la taille optimale des blocs pourrait être de 1k (512*2) ou de 2k (512*4). En revanche, il ne sert à rien d'être trop gourmand et d'utiliser une taille de bloc de 5k (512*10) ou quelque chose d'excessif ; Le système finira par s'engorger au niveau de l'appareil lui-même et vous ne serez pas en mesure de tirer des performances supplémentaires du processus de sauvegarde. (soulignement ajouté)

Je pense que la différence de performance entre une taille de bloc quasi optimale et optimale pour une configuration donnée est négligeable, à moins que l'ensemble de données ne soit énorme. En effet, un utilisateur de FixUnix (post de 2007) a affirmé que ses temps optimaux n'étaient que 5% plus rapides que les temps sous-optimaux. Peut-être pouvez-vous obtenir un peu plus d'efficacité en utilisant un multiple de la taille du "cluster" ou de la taille des blocs du système de fichiers.

Bien entendu, si vous vous éloignez trop de la taille optimale des blocs, vous rencontrerez des problèmes.

En définitive, vous ne gagnerez probablement qu'environ 5 % de performance (c'est-à-dire 3 minutes par heure) avec la taille de bloc optimale absolue, alors demandez-vous si cela vaut la peine de consacrer du temps et des efforts à des recherches plus approfondies. Tant que vous restez à l'écart des valeurs extrêmes, vous ne devriez pas en souffrir.

Chaque transfert de disque génère une interruption que le processeur doit gérer. Un disque typique de 50 Mb/s voudra en générer 100 000 par seconde à une taille de bloc de 512 bits Un processeur normal en traiterait des dizaines de milliers, c'est pourquoi une taille de bloc plus grande (2^x) serait plus pratique (4k comme taille de bloc FS par défaut dans la plupart des systèmes jusqu'à 64k comme taille ISA DMA)...