Jak poprawnie wyrównać tabelę partycji?

Jestem w trakcie budowy mojej pierwszej macierzy RAID5. Użyłem mdadm do utworzenia następującego zestawu:

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

W tym czasie postanowiłem sformatować bestię za pomocą następującego polecenia:

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

Nie jestem pewien, co zrobić z „wyrównaniem / dev / md1p1 jest przesunięte o 63488 bajtów”. i jak prawidłowo partycjonować dyski, aby je dopasować, aby móc je odpowiednio sformatować.

Ponieważ wyrównanie pojawia się w wielu miejscach -

• Dyski twarde „Advanced Format” z blokami 4k
• Dyski SSD
• NALOT
• LVM

- Rozwińę trochę pytanie.

Wyrównanie partycji

„Linux na dyskach sektora 4kB” (IBM developerWorks) prowadzi przez fdisk, parted i GPT fdisk.

Z 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

Wyrównanie systemu plików

Dotyczy to przede wszystkim RAID (poziomy 0, 5 i 6; nie poziom 1); system plików działa lepiej, jeśli jest tworzony ze znajomością rozmiarów pasków.

Może być również używany do dysków SSD, jeśli chcesz wyrównać system plików do rozmiaru bloku wymazywania SSD (Theodore Tso, programista jądra Linux).

W poście PO mkfsnajwyraźniej automatycznie wykrył optymalne ustawienia, więc nie było żadnych dalszych działań.

Jeśli chcesz to zweryfikować, dla RAID odpowiednie parametry to:

• rozmiar bloku ( rozmiar bloku systemu plików, np. 4096)
• rozmiar paska (taki sam jak rozmiar porcji mdadm, np. 64k)
• krok: stripe size / block size (np. 64k / 4k = 16)
• szerokość paska: stride * #-of-data-disks (np. 4 dyski RAID 5 to 3 dyski danych; 16 * 3 = 48)

Z Linux Raid Wiki . Zobacz także ten prosty kalkulator dla różnych poziomów RAID i liczby dysków.

W przypadku wyrównania bloku kasowania SSD parametry są następujące:

• rozmiar bloku fs (np. 4096)
• Rozmiar bloku kasowania SSD (np. 128k)
• stripe-width: erase-block-size / fs-block-size (np. 128k / 4k = 32)

Ze stanowiska Theodore SSD .

Wyrównanie zakresu LVM

Potencjalnym problemem jest to, że LVM tworzy nagłówek 192k. Jest to wielokrotność 4k (więc nie ma problemu z dyskami o wielkości 4k bloków), ale może nie być wielokrotnością rozmiaru paska RAID (jeśli LVM działa na RAID) lub rozmiaru bloku wymazywania SSD (jeśli LVM działa na SSD).

Obejście problemu można znaleźć w poście Theodore .

Mój przyjaciel zauważył, że mogę po prostu mkfs.ex4 od razu /dev/md1bez partycjonowania, więc usunąłem partycję i zrobiłem to i wygląda na to, że teraz formatuje.

Uważam, że ten sposób jest najłatwiejszy

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

lub alternatywna brudna metoda po prostu wyglądałaby tak

(parted) mkpart primary ext4 1 -1

Wygląda na to, że mkfs.ext4 chce, aby systemy plików na macierzy RAID uruchomiły się na granicy 64 KiB. Jeśli używasz całego dysku, zaczyna się on od 0, co jest oczywiście wielokrotnością 64 KiB ...

Większość narzędzi do partycjonowania i tak będzie domyślnie używać granicy 1 MiB (fdisk prawdopodobnie nie).

Powodem tego jest fakt, że większość dysków twardych i dysków SSD używa sektorów fizycznych na urządzeniu, które są znacznie większe niż sektory logiczne. Powoduje to, że jeśli odczytujesz sektor logiczny o wielkości 512 bajtów z dysku, sprzęt faktycznie musi odczytać znacznie większą ilość danych.

W przypadku programowego urządzenia RAID dzieje się coś podobnego: dane na nim są przechowywane w „porcjach” 64 KiB z domyślnymi ustawieniami mdadm.