Як правильно вирівняти таблицю розділів?


19

Я зараз будую свій перший масив RAID5. Я використовував mdadm для створення наступних налаштувань:

root@bondigas:~# mdadm --detail /dev/md1
/dev/md1:
        Version : 00.90
  Creation Time : Wed Oct 20 20:00:41 2010
     Raid Level : raid5
     Array Size : 5860543488 (5589.05 GiB 6001.20 GB)
  Used Dev Size : 1953514496 (1863.02 GiB 2000.40 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Wed Oct 20 20:13:48 2010
          State : clean, degraded, recovering
 Active Devices : 3
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

 Rebuild Status : 1% complete

           UUID : f6dc829e:aa29b476:edd1ef19:85032322 (local to host bondigas)
         Events : 0.12

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
       2       8       48        2      active sync   /dev/sdd
       4       8       64        3      spare rebuilding   /dev/sde

Хоча це відбувається, я вирішив відформатувати звіра за допомогою наступної команди:

root@bondigas:~# mkfs.ext4 /dev/md1p1 
mke2fs 1.41.11 (14-Mar-2010)
/dev/md1p1 alignment is offset by 63488 bytes.
This may result in very poor performance, (re)-partitioning suggested.
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=16 blocks, Stripe width=48 blocks
97853440 inodes, 391394047 blocks
19569702 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
11945 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
        102400000, 214990848

Writing inode tables: ^C 27/11945
root@bondigas:~# ^C

Я не впевнений, що робити щодо "/ dev / md1p1 вирівнювання компенсується 63488 байтами." і як правильно розділити диски на відповідність, щоб я міг їх правильно відформатувати.

Відповіді:


17

Оскільки вирівнювання спливає в багатьох місцях -

  • Жорсткі диски "розширеного формату" з блоками 4k
  • SSD-диски
  • РАЙД
  • НВМ

- Я трохи розгорну питання.

Вирівнювання перегородок

"Linux на 4kB-секторних дисках" (IBM developerWorks) проходить через кроки з fdisk, parted та GPT fdisk.

З fdisk:

sudo fdisk /dev/XXX 
c # turn off DOS compatibility
u # switch to sector units
p # print current partitions, check that start sectors are multiples of 8

# for a new partition:
n # new partition
<select primary/secondary and partition #>
first sector: 2048 
  # 2048 is default in recent fdisk, 
  # and is compatible with Vista and Win 7, 
  # 4k-sector disks and all common RAID stripe sizes

Вирівнювання файлової системи

Це насамперед актуально для RAID (рівні 0, 5 та 6; не рівень 1); файлова система працює краще, якщо вона створена із знанням розмірів смуг.

Його також можна використовувати для SSD, якщо ви хочете вирівняти файлову систему за розміром блоку стирання SSD (Теодор Цо, розробник ядра Linux).

На посаді ОП, mkfsочевидно, автоматично виявлено оптимальні налаштування, тому подальших дій не потрібно було.

Якщо ви хочете перевірити, для RAID відповідними параметрами є:

  • розмір блоку ( розмір блоку файлової системи, напр., 4096)
  • розмір смужки (такий же, як розмір шматка mdadm, наприклад 64 к)
  • крок: stripe size / block size (наприклад, 64k / 4k = 16)
  • ширина смуги: stride * #-of-data-disks (наприклад, 4 диски RAID 5 - це 3 диски даних; 16 * 3 = 48)

З Linux Raid Wiki . Дивіться також цей простий калькулятор для різних рівнів RAID та кількості дисків.

Для вирівнювання блоку стирання SSD параметрами є:

  • розмір блоку fs (наприклад, 4096)
  • Розмір блоку SSD для стирання (наприклад, 128 к)
  • ширина смуги: стирання-розмір блоку / fs-блок-розмір (наприклад, 128k / 4k = 32)

З поста SSD Теодора .

Вирівнювання розширень LVM

Потенційна проблема полягає в тому, що LVM створює заголовок 192k. Це кратне 4k (тому жодних проблем із блоками 4k-блоків), але може не бути кратним розміром смуги RAID (якщо LVM працює на RAID) або розміром блоку стирання SSD (якщо LVM працює на SSD).

Дивіться допис Теодора для вирішення.


@Marco Як так? Перший, для IBM Developer Works, навіть має орієнтовний графік покарання за ефективність запису за використання нерівних розділів та бічну панель для RAID. З моменту написання цього запису блог від Tso про вирівнювання SSD перемістився принаймні двічі. Ще раз оновлено посилання, але немає гарантії, що воно буде працювати.
jg-faustus

Альтернативне посилання на SSD: Вирівнювання розділів SSD
jg-faustus

8

Мій друг зазначив, що я можу просто ввімкнути mkfs.ex4, /dev/md1не розділяючи нічого, тому я видалив розділ і зробив це, і, здається, це форматування зараз.


6

Я вважаю цей спосіб найпростішим

parted -a opt /dev/md0
(parted) u MiB
(parted) rm 1
(parted) mkpart primary 1 100%

або альтернативний брудний метод просто піде так

(parted) mkpart primary ext4 1 -1

Розділена документація пропонує використовувати MB та GB, а не MiB чи GiB, якщо хочеться дозволити parted намагатися оптимізувати розділи автоматично.
Феліпе Альварес

1

Схоже, mkfs.ext4 хоче, щоб файлові системи у вашому RAID запускалися на 64-кібайтній межі. Якщо ви використовуєте весь диск, він починається з 0, що, звичайно, також є кратним 64 KiB ...

Більшість інструментів розбиття на сьогоднішній день так чи інакше використовуватиме межу в 1 МіБ (мабуть, fdisk не має).

Причиною цього є те, що більшість жорстких дисків та SSD-дисків використовують на пристрої фізичні сектори, які набагато більше, ніж логічні сектори. Результатом цього є те, що якщо ви читаєте логічний сектор у 512 байт з диска, апаратне забезпечення насправді має зчитувати набагато більший обсяг даних.

У випадку із вашим програмним RAID-пристроєм трапляється щось подібне: дані на ньому зберігаються в "шматках" 64 KiB із налаштуваннями mdadm за замовчуванням.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.