Pregunta sectores mdadm y 4k (formato avanzado)


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

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

La página del manual dice esto:

Las diferentes subversiones almacenan la   superbloque en diferentes ubicaciones en   El 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". "predeterminado" 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 tiene una longitud de unos 200 bytes, si recuerdo bien).

Cualquier información sobre esto es bienvenida.

editar:

a continuación se respondió que mdadm superblock 1.1 y 1.2 están diseñados para alineación 4k. Acabo de crear una incursión de 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 está sincronizando 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 computadora de escritorio y se sincronizan a aproximadamente 80 MB / s).

Edit2:

Aquí está la salida de

# 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 compensación de datos es de 2048 sectores, que es divisible por 8, por lo que uno podría pensar que está bien. El grupo de volúmenes tiene un tamaño de extensión física de 4 MiB, que también se puede dividir por 8. Pero eso no importaría, ya que la sincronizació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 última etapa e incluso eso se rompió en algún momento. Un disco de reemplazo funcionó bien.


8
2018-05-27 21:16


origen




Respuestas:


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

Con los superbloques 1.1 y 1.2, el espacio se reserva al comienzo de cada disco para que el superbloque no se pisotee. El código de creación del superbloque obliga a que este espacio reservado sea un múltiplo de 4kB. Todas las lecturas físicas están compensadas 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 divide uniformemente en 4kB.

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

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

Y esto data_offset parámetro es usado por el Código RAID1 en el kernel para compensar las lecturas físicas, por ejemplo en el camino de lectura:

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

11
2018-05-28 03:42



Si tanto 1.1 como 1.2 son adecuados para la alineación 4k, ¿para qué sirve la versión 1.2? Quiero decir, ¿por qué querría que el superbloque comience 4k desde el principio? - Halfgaar
Es así que el inicio del disco se puede reservar para bloques de arranque, permitiendo que el disco se use como un disco de arranque. - Tom Shaw
Acabo de actualizar mi post. Por lo que parece, mi nueva matriz no está alineada correctamente. - Halfgaar