setores mdadm e 4k (formato avançado)

Existem várias perguntas no Serverfault sobre o alinhamento de discos de setores de 4k, mas uma coisa ainda não está clara para mim.

Alinhei com sucesso meu RAID1 + LVM. Uma das coisas que fiz foi usar o mdadm superblock versão 1.0 (que armazena o superblock no final do disco).

A página de manual diz o seguinte:

As diferentes sub-versões armazenam o superbloco em diferentes locais do dispositivo, no final (para 1.0), no início (para 1.1) ou 4K desde o início (para 1.2). "1" é equivalente a "1.0". "padrão" é equivalente a "1.2".

A versão 1.2, que é o padrão, é feita para unidades de setores de 4k? Do jeito que eu vejo, não é, porque 4k desde o início + o comprimento do superbloco não é uma multidão de 4k (o superbloco tem cerca de 200 bytes, se bem me lembro).

Qualquer visão sobre isso é bem-vinda.

editar:

abaixo foi respondido que o mdadm superblock 1.1 e 1.2 se destina ao alinhamento de 4k. Acabei de criar um ataque de dispositivo inteiro com:

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

Então eu adicionei um volume lógico a ele:

vgcreate universe2 /dev/md4

A matriz 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

Por isso, duvido que esteja devidamente alinhado.

(os discos têm WD EARS de 1,5 TB. Eu os tenho no meu PC desktop e eles são sincronizados a cerca de 80 MB / s.)

Edit2:

Aqui está a saída --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)

O deslocamento de dados é de 2048 setores, que é divisível por 8, então alguém poderia pensar que está tudo bem. O grupo de volumes possui um tamanho de extensão física de 4 MiB, que também é divisível por 8. Mas isso nem importa, porque a ressincronização não está relacionada ao que o dispositivo contém.

Outra edição: não parece ser um problema de alinhamento; pois o hdparm -t mostra uma velocidade de leitura muito baixa para um dos discos (30 MB / s). Outra coisa está errada.

Edit2: Eu nunca me lembro de atualizar este post quando encontrei a resposta. Tudo está bem alinhado. Um dos discos estava quebrado. Aparentemente, estava na última perna e até isso quebrou em algum momento. Um disco de substituição funcionou bem.

Sim, é feito para o alinhamento do setor em 4k.

Nos superblocos 1.1 e 1.2, o espaço é reservado no início de cada disco para que o superbloco não seja pisoteado. O código de criação do superbloco força esse espaço reservado a ser um múltiplo de 4kB. Todas as leituras físicas são deslocadas do final deste espaço reservado , não do final do superbloco. Portanto, isso preserva o alinhamento para qualquer tamanho de setor que se divida uniformemente em 4kB.

Se você estiver interessado, aqui está a prova do código-fonte mdadm ( super1.c):

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

E este data_offsetparâmetro é usado pelo código RAID1 no kernel para compensar as leituras físicas, por exemplo, no caminho de leitura:

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