mdadm raid1 et quelle taille de bloc (ou taille de bloc) sur les lecteurs 4k?

13

Je veux utiliser deux disques de 3 To dans une configuration mdadm raid1 (en utilisant Debian Sequeeze).

Les lecteurs utilisent des secteurs matériels 4k au lieu des secteurs traditionnels de 512 octets.

Je suis un peu confus car d'une part le noyau rapporte:

$ cat /sys/block/sdb/queue/hw_sector_size
512

Mais d'autre part fdiskrapporte:

# fdisk -l /dev/sdb
Disk /dev/sdb: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Ainsi, il semble que le noyau ait une idée que le lecteur utilise des secteurs 4k.

La mdadmpage de manuel est un peu énigmatique sur la taille des morceaux et le raid1:

   -c, --chunk=
          Specify chunk size of kibibytes.  The default when  creating  an
          array  is 512KB.  To ensure compatibility with earlier versions,
          the default when Building and array with no persistent  metadata
          is  64KB.   This  is  only  meaningful  for RAID0, RAID4, RAID5,
          RAID6, and RAID10.

Pourquoi n'est-il pas significatif pour raid1?

En regardant /proc/mdstat, le dispositif raid1 md8 a 2930265424 blocs, c.-à-d.

3000591794176/2930265424/2 = 512

Utilise-t-il mdadmalors une taille de bloc de 512 octets? (/ 2 car c'est un miroir bidirectionnel)

Et la taille des morceaux est-elle un concept différent de la taille des blocs?

Essayer de laisser mdadm expliquer un appareil:

# mdadm -E /dev/sdb -v -v
Avail Dev Size : 5860531120 (2794.52 GiB 3000.59 GB)
Array Size : 5860530848 (2794.52 GiB 3000.59 GB)

3000591794176/5860530848 = 512

Avec une valeur par défaut mkfs.xfssur le périphérique md, il signale:

sectsz=512
bsize=4096

J'ai corrigé cela avec un appel de mkfs.xfs -s size=4096 /dev/md8

Edit: En testant un peu autour, j'ai remarqué les choses suivantes:

Il semble que la resynchronisation initiale se fasse avec une taille de bloc de 128k (et non 512 octets):

md: resync of RAID array md8
md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for resync.
md: using 128k window, over a total of 2930265424 blocks.

La vitesse affichée via /proc/mdstatest cohérente pour cette taille de bloc (pour 512 octets, on peut s'attendre à un impact sur les performances):

[>....................]  resync =  3.0% (90510912/2930265424) finish=381.1min speed=124166K/sec

(Par exemple, lors de la désactivation du cache d'écriture, la vitesse affichée tombe immédiatement à 18 m / s)

Sous /sysil y a en fait quelques fichiers plus pertinents en plus hw_sector_size:

# cat /sys/block/sdb/queue/physical_block_size
4096
# cat  /sys/block/sdb/queue/logical_block_size
512

Cela signifie que le lecteur ne ment pas au noyau au sujet de sa taille de secteur 4k et que le noyau a une prise en charge du secteur 4k (comme la sortie de fstab -lsuggéré).

Googler un peu autour a donné lieu à quelques rapports sur les disques WD, qui ne signalent pas la taille 4k - heureusement, ce disque WD de 3 To ne le fait pas - peut-être que WD a corrigé son firmware avec les disques actuels.

maxschlepzig
la source

Réponses:

16

La taille des morceaux ne s'applique pas à raid1 car il n'y a pas de rayures; essentiellement le disque entier est un morceau. En bref, vous n'avez pas à vous soucier de la taille du secteur physique 4k. Les versions récentes de mdadm utilisent les informations du noyau pour s'assurer que le début des données est aligné sur une limite de 4 Ko. Assurez-vous simplement que vous utilisez un format de métadonnées 1.x.

psusi
la source