сектора mdadm и 4k (расширенный формат)

На Serverfault есть множество вопросов о выравнивании дисков 4k секторов, но одна вещь мне пока не совсем понятна.

Я успешно выровнял мой RAID1 + LVM. Одна из вещей, которые я сделал, - это использование суперблока mdadm версии 1.0 (который хранит суперблок в конце диска).

Manpage говорит это:

Различные подверсии хранят суперблок в разных местах на устройстве, либо в конце (для 1.0), в начале (для 1.1) или в 4K от начала (для 1.2). «1» эквивалентно «1,0». «default» эквивалентно «1.2».

Версия 1.2, которая по умолчанию, сделана для дисков 4k секторов? На мой взгляд, это не так, потому что 4k от начала + длина суперблока не является множеством 4k (суперблок имеет длину около 200 байт, если я правильно помню).

Любое понимание этого приветствуется.

редактировать:

ниже ответили, что суперблок mdadm 1.1 и 1.2 предназначен для выравнивания 4k. Я только что создал рейд для всего устройства с:

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

Затем я добавил к нему логический том:

vgcreate universe2 /dev/md4

Массив синхронизируется со скоростью 16 МБ / с:

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

Поэтому я сомневаюсь, что это правильно выровнено.

(Диски WAR EARS 1,5 ТБ. У меня они есть на настольном ПК, и они синхронизируются со скоростью около 80 МБ / с.)

Edit2:

Вот вывод --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)

Смещение данных составляет 2048 секторов, которые делятся на 8, поэтому можно подумать, что это нормально. Группа томов имеет размер физического экстента 4 МБ, который также делится на 8. Но это даже не имеет значения, потому что повторная синхронизация не связана с тем, что содержит устройство.

Другое редактирование: похоже, это не проблема выравнивания; поскольку hdparm -t показывает очень низкую скорость чтения для одного из дисков (30 МБ / с). Что-то еще не так.

Edit2: я никогда не помню, чтобы обновить этот пост, когда я нашел ответ. Все хорошо выровнено. Один из дисков был сломан. Видимо, это было на последнем этапе, и даже это сломалось в какой-то момент. Запасной диск работал нормально.

Да, это сделано для выравнивания сектора 4k.

При использовании суперблоков 1.1 и 1.2 в начале каждого диска резервируется место, чтобы суперблок не растоптался. Код создания суперблока заставляет это зарезервированное пространство быть кратным 4 КБ. Все физические чтения смещены от конца этого зарезервированного пространства , а не от конца суперблока. Таким образом, это сохраняет выравнивание для любого размера сектора, который делится равномерно на 4 КБ.

Если вам интересно, вот доказательство из исходного кода mdadm ( super1.c):

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

И этот data_offsetпараметр используется кодом RAID1 в ядре для компенсации физического чтения, например, в пути чтения:

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