settori mdadm e 4k (formato avanzato)

Ci sono numerose domande su Serverfault sull'allineamento dei dischi di settori 4K, ma una cosa non mi è ancora chiara.

Ho allineato con successo il mio RAID1 + LVM. Una delle cose che ho fatto è stato usare mdadm superblock versione 1.0 (che memorizza il superblocco alla fine del disco).

La manpage dice questo:

Le diverse sotto-versioni memorizzano il superblocco in diverse posizioni sul dispositivo, alla fine (per 1.0), all'inizio (per 1.1) o 4K dall'inizio (per 1.2). "1" equivale a "1.0". "default" equivale a "1.2".

La versione 1.2, che è di default, è progettata per unità a settori 4k? Per come la vedo io non lo è, perché 4k dall'inizio + la lunghezza del superblocco non è una moltitudine di 4k (il superblocco è lungo circa 200 byte, se ricordo bene).

Qualsiasi approfondimento in merito è il benvenuto.

modificare:

di seguito è stato risposto che mdadm superblock 1.1 e 1.2 sono pensati per l'allineamento 4k. Ho appena creato un raid per l'intero dispositivo con:

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

Quindi ho aggiunto un volume logico ad esso:

vgcreate universe2 /dev/md4

L'array si sta sincronizzando 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

Quindi dubito che sia correttamente allineato.

(i dischi sono 1,5 TB WD EARS. Li ho nel mio PC desktop e sono sincronizzati a circa 80 MB / s.)

Edit2:

Ecco - esaminare l'output:

# 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 compensazione dei dati è di 2048 settori, che è divisibile per 8, quindi si potrebbe pensare che sia ok. Il gruppo di volumi ha una dimensione fisica di 4 MiB, che è anche divisibile per 8. Ma questo non avrebbe importanza, perché la risincronizzazione non è correlata a ciò che contiene il dispositivo.

Un'altra modifica: non sembra essere un problema di allineamento; poiché hdparm -t mostra una velocità di lettura molto bassa per uno dei dischi (30 MB / s). Qualcos'altro non va.

Edit2: non ricordo mai di aggiornare questo post quando ho trovato la risposta. Tutto è ben allineato. Uno dei dischi era rotto. Apparentemente era all'ultima gamba e anche a un certo punto si è rotto. Un disco sostitutivo ha funzionato bene.

Sì, è realizzato per l'allineamento del settore 4k.

Con i superblocchi 1.1 e 1.2, lo spazio è riservato all'inizio di ogni disco in modo che il superblocco non venga calpestato. Il codice di creazione del superblocco impone che questo spazio riservato sia un multiplo di 4 KB. Tutte le letture fisiche sono sfalsate dalla fine di questo spazio riservato , non dalla fine del superblocco. Ciò preserva quindi l'allineamento per qualsiasi dimensione di settore che si divide uniformemente in 4kB.

Se sei interessato, ecco la prova dal codice sorgente mdadm ( super1.c):

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

E questo data_offsetparametro viene utilizzato dal codice RAID1 nel kernel per compensare le letture fisiche, ad esempio nel percorso di lettura:

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