Question secteurs mdadm et 4k (format avancé)


Serverfault soulève de nombreuses questions sur l'alignement des disques de secteurs 4k, mais une chose n'est pas encore claire pour moi.

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

La page de manuel dit ceci:

Les différentes sous-versions stockent les   superbloc à différents endroits 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". "défaut" est   équivalent à "1.2".

La version 1.2, par défaut, est-elle conçue pour les lecteurs de secteurs 4k? Comme 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 a environ 200 octets de long, si je me souviens bien).

Toute idée de cela est la bienvenue.

modifier:

Vous trouverez ci-dessous une réponse indiquant que mdadm superblock 1.1 et 1.2 sont destinés à un alignement 4k. Je viens de créer un raid sur tout le périphérique avec:

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

Ensuite, j'ai ajouté un volume logique:

vgcreate universe2 /dev/md4

La matrice 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

Donc, je doute qu'il soit correctement aligné.

(Les disques sont des oreillettes WD de 1,5 To. Je les ai sur mon ordinateur de bureau et ils se sont synchronisés à 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)

Le décalage de données correspond à 2 048 secteurs, ce qui est divisible par 8, alors on pourrait penser que c'est correct. Le groupe de volumes a une étendue physique de 4 Mio, divisable également par 8. Cela n'a pas d'importance, car la resynchronisation n'est pas liée à ce que contient le périphérique.

Une autre édition: cela ne semble pas être un problème d'alignement; depuis hdparm -t affiche une vitesse de lecture très faible pour l’un des disques (30 Mo / s). Quelque chose 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 jambe et même cela a cassé à un moment donné. Un disque de remplacement a bien fonctionné.


8
2018-05-27 21:16


origine




Réponses:


Oui, il est conçu pour un alignement de 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 du superbloc oblige cet espace réservé à être un multiple de 4 ko. Toutes les lectures physiques sont décalées à partir de la fin de cet espace réservé, pas à partir de la fin du superbloc. Cela préserve donc l'alignement pour toute taille de secteur qui se divise également en 4 Ko.

Si cela vous intéresse, voici la preuve de le code source de mdadm (super1.c):

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

Et ça data_offset paramètre est utilisé par le Code RAID1 dans le noyau pour compenser les lectures physiques, par ex. dans le chemin de lecture:

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

11
2018-05-28 03:42



Si les versions 1.1 et 1.2 conviennent à l'alignement 4k, à quoi sert la version 1.2? Je veux dire, pourquoi voudrais-je que le superbloc démarre 4k dès le début? - Halfgaar
C'est pour que le début du disque puisse être réservé aux blocs de démarrage, permettant ainsi au disque d'être utilisé comme disque de démarrage. - Tom Shaw
Je viens de mettre à jour mon post. En apparence, mon nouveau tableau n'est pas correctement aligné. - Halfgaar