mdadm y sectores 4k (formato avanzado)

Existen numerosas preguntas en Serverfault sobre la alineación de discos de 4k sectores, pero una cosa aún no me queda clara.

Alineé con éxito mi RAID1 + LVM. Una de las cosas que hice fue usar mdadm superblock versión 1.0 (que almacena el superbloque al final del disco).

La página de manual dice esto:

Las diferentes sub versiones almacenan el superbloque en diferentes ubicaciones del dispositivo, ya sea al final (para 1.0), al inicio (para 1.1) o 4K desde el inicio (para 1.2). "1" es equivalente a "1.0". "default" es equivalente a "1.2".

¿La versión 1.2, que es la predeterminada, está hecha para unidades de 4k sectores? A mi modo de ver, no lo es, porque 4k desde el inicio + la longitud del superbloque no es una multitud de 4k (el superbloque es de unos 200 bytes de largo, si no recuerdo mal).

Cualquier idea sobre esto es bienvenida.

editar:

a continuación se respondió que mdadm superblock 1.1 y 1.2 están destinados a la alineación 4k. Acabo de crear una incursión en todo el dispositivo con:

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

Luego le agregué un volumen lógico:

vgcreate universe2 /dev/md4

La matriz se sincroniza a 16 MB / 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

Así que dudo que esté correctamente alineado.

(los discos son de 1.5 TB WD EARS. Los tengo en mi PC de escritorio y se sincronizaron a unos 80 MB / s).

Edit2:

Aquí está la salida de examen:

# 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)

El desplazamiento de datos es de 2048 sectores, que es divisible por 8, por lo que uno pensaría que está bien. El grupo de volúmenes tiene un tamaño de extensión física de 4 MiB, que también es divisible por 8. Pero eso ni siquiera importaría, porque la resincronización no está relacionada con lo que contiene el dispositivo.

Otra edición: no parece ser un problema de alineación; ya que hdparm -t muestra una velocidad de lectura muy baja para uno de los discos (30 MB / s). Algo más está mal.

Edit2: nunca recuerdo actualizar esta publicación cuando encontré la respuesta. Todo está muy bien alineado. Uno de los discos estaba roto. Aparentemente estaba en su último tramo e incluso eso se rompió en algún momento. Un disco de reemplazo funcionó bien.

Sí, está hecho para la alineación del sector 4k.

Con los superbloques 1.1 y 1.2, el espacio está reservado al comienzo de cada disco para que el superbloque no sea pisoteado. El código de creación de superbloque obliga a este espacio reservado a ser un múltiplo de 4kB. Todas las lecturas físicas se compensan desde el final de este espacio reservado , no desde el final del superbloque. Por lo tanto, esto preserva la alineación para cualquier tamaño de sector que se divida uniformemente en 4kB.

Si está interesado, aquí está la prueba del código fuente mdadm ( super1.c):

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

Y este data_offsetparámetro lo utiliza el código RAID1 en el núcleo para compensar las lecturas físicas, por ejemplo, en la ruta de lectura:

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