mdadm e setores 4k (formato avançado)

Question

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

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

A manpage diz isso:

The different sub-versions store the superblock at different locations on the device, either at the end (for 1.0), at the start (for 1.1) or 4K from the start (for 1.2). "1" is equivalent to "1.0". "default" is equivalent to "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 multitude de 4k (o superbloco tem cerca de 200 bytes, se bem me lembro).

Qualquer informação sobre isso é bem-vinda.

editar:

abaixo foi respondido que o superbloco 1.1 e 1.2 do mdadm são destinados ao alinhamento 4k. Acabei de criar um ataque de dispositivo inteiro com:

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

Em seguida, adicionei um volume lógico a ele:

vgcreate universe2 /dev/md4

O array 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

Então, duvido que esteja alinhado corretamente.

(os discos são de 1,5 TB WD EARS. Eu os tenho em meu PC de mesa e eles sincronizaram a cerca de 80 MB / s.)

Editar2:

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 desvio de dados é de 2048 setores, divididos por 8, portanto, seria razoável. O grupo de volumes tem um tamanho de extensão física de 4 MiB, que também é divisível por 8. Mas isso nem importaria, porque a ressincronização não está relacionada ao conteúdo do dispositivo.

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

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

    

Answer 1

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

Com superblocos 1.1 e 1.2, o espaço é reservado no início de cada disco para que o superbloco não seja pisado. O código de criação de superblocos 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 a partir do final do superbloco. Isso, portanto, 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 do mdadm ( super1.c ):

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

E esse parâmetro data_offset é 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