secteurs mdadm et 4k (format avancé)

Il y a de nombreuses questions sur Serverfault concernant l'alignement des disques des secteurs 4k, mais une chose n'est pas encore très claire pour moi.

J'ai aligné avec succès mon RAID1 + LVM. L'une des choses que j'ai faites a été d'utiliser la version 1.0 du superbloc mdadm (qui stocke le superbloc à la fin du disque).

La page de manuel dit ceci:

Les différentes sous-versions stockent le superbloc à différents emplacements sur l'appareil, soit à la fin (pour 1.0), au début (pour 1.1) ou 4K depuis le début (pour 1.2). "1" est équivalent à "1.0". "default" est équivalent à "1.2".

La version 1.2, qui est par défaut, est-elle conçue pour les lecteurs de secteurs 4k? La façon dont je le vois, ce n'est pas le cas, car 4k depuis le début + la longueur du superbloc n'est pas une multitude de 4k (le superbloc fait environ 200 octets de long, si je me souviens bien).

Toute information à ce sujet est la bienvenue.

Éditer:

ci-dessous, il a été répondu que les superblocs mdadm 1.1 et 1.2 sont destinés à l'alignement 4k. Je viens de créer un raid complet avec:

mdadm --create /dev/md4 -l 1 -n 2 /dev/sdb /dev/sdd

Ensuite, je lui ai ajouté un volume logique:

vgcreate universe2 /dev/md4

La baie se synchronise à 16 Mo / s:

md4 : active raid1 sdd[1] sdb[0]
      1465137424 blocks super 1.2 [2/2] [UU]
      [>....................]  resync =  0.8% (13100352/1465137424) finish=1471.6min speed=16443K/sec

Je doute donc qu'il soit correctement aligné.

(Les disques font 1,5 To WD EARS. Je les ai sur mon ordinateur de bureau et ils se synchronisent à environ 80 Mo / s.)

Edit2:

Voici la sortie --examine:

# mdadm --examine /dev/sdb
/dev/sdb:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 79843828:7d939cce:1c8f0b32:cf339870
           Name : brick:4  (local to host brick)
  Creation Time : Sat Jul  9 10:47:33 2011
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 2930275120 (1397.26 GiB 1500.30 GB)
     Array Size : 2930274848 (1397.26 GiB 1500.30 GB)
  Used Dev Size : 2930274848 (1397.26 GiB 1500.30 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : active
    Device UUID : dd2e3b5f:33214b96:1cb88169:25deb050

    Update Time : Sat Jul  9 10:49:06 2011
       Checksum : 4f7cd785 - correct
         Events : 1


   Device Role : Active device 0
   Array State : AA ('A' == active, '.' == missing)

La compensation des données est de 2048 secteurs, divisibles par 8, donc on pourrait penser que c'est ok. Le groupe de volumes a une taille d'extension physique de 4 Mio, qui est également divisible par 8. Mais cela n'aurait même pas d'importance, car la resynchronisation n'est pas liée à ce que contient l'appareil.

Une autre modification: il ne semble pas être un problème d'alignement; puisque hdparm -t affiche une vitesse de lecture très faible pour l'un des disques (30 Mo / s). Quelque chose d'autre ne va pas.

Edit2: Je ne me souviens jamais de mettre à jour ce message lorsque j'ai trouvé la réponse. Tout est bien aligné. L'un des disques était cassé. Apparemment, c'était sur sa dernière étape et même cela s'est cassé à un moment donné. Un disque de remplacement a bien fonctionné.

Oui, il est fait pour l'alignement du secteur 4k.

Avec les superblocs 1.1 et 1.2, un espace est réservé au début de chaque disque afin que le superbloc ne soit pas piétiné. Le code de création de superbloc oblige cet espace réservé à être un multiple de 4 Ko. Toutes les lectures physiques sont décalées de la fin de cet espace réservé , et non de la fin du superbloc. Cela préserve donc l'alignement pour toute taille de secteur qui se divise uniformément en 4 Ko.

Si vous êtes intéressé, voici la preuve du code source mdadm ( super1.c):

/* force 4K alignment */
reserved &= ~7ULL;
sb->data_offset = __cpu_to_le64(reserved);

Et ce data_offsetparamètre est utilisé par le code RAID1 dans le noyau pour compenser les lectures physiques, par exemple dans le chemin de lecture:

read_bio->bi_sector = r1_bio->sector + mirror->rdev->data_offset