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

На Serverfault є чимало питань щодо вирівнювання дисків 4k секторів, але одне мені ще не зовсім зрозуміло.

Я успішно вирівняв свій RAID1 + LVM. Однією з речей я був використання mdadm superblock версії 1.0 (який зберігає суперблок в кінці диска).

На сторінці написано таке:

Різні під-версії зберігають суперблок у різних місцях на пристрої, або в кінці (для 1,0), на старті (для 1,1) або 4К від початку (для 1,2). "1" еквівалентно "1,0". "за замовчуванням" еквівалентно "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

Тому я сумніваюся, що він правильно вирівняний.

(диски - 1,5 ТБ WD EARS. У мене вони є на настільному ПК, і вони синхронізовані зі швидкістю близько 80 Мб / с.)

Edit2:

Ось висновок --дослідження:

# 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