Bölümleme tablomu nasıl düzgün bir şekilde hizalayabilirim?


19

İlk RAID5 dizimi oluşturma sürecindeyim. Aşağıdaki kurulumu oluşturmak için mdadm kullandım:

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

Bu sırada canavarı aşağıdaki komutla biçimlendirmeye karar verdim:

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 hizalaması 63488 bayt tarafından dengeleniyor" konusunda ne yapacağımdan emin değilim. ve düzgün şekilde biçimlendirebilmem için disklerin uygun şekilde nasıl bölümleneceği.

Yanıtlar:


17

Hizalama birçok yerde ortaya çıktığı için -

  • 4k bloklu "Gelişmiş Format" sabit diskler
  • SSD'ler
  • RAID
  • LVM

- Soruyu biraz genişleteceğim.

Bölümleri hizalama

"4kB sektör disklerinde Linux" (IBM developerWorks) fdisk, parted ve GPT fdisk ile adım adım ilerler.

Fdisk ile:

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

Dosya sistemini hizalama

Bu öncelikle RAID için geçerlidir (seviye 0, 5 ve 6; seviye 1 değil); şerit boyutu bilgisi ile oluşturulmuşsa dosya sistemi daha iyi performans gösterir.

Dosya sistemini SSD silme bloğu boyutuna (Theodore Tso, Linux çekirdek geliştiricisi) hizalamak isterseniz SSD'ler için de kullanılabilir .

OP postunda mkfsgörünüşte en uygun ayarları otomatik olarak algıladı, bu yüzden başka bir işlem yapılması gerekmedi.

Doğrulamak isterseniz, RAID için ilgili parametreler şunlardır:

  • blok boyutu (dosya sistemi blok boyutu, ör. 4096)
  • şerit boyutu (mdadm yığın boyutuyla aynı, ör. 64k)
  • adım: stripe size / block size (ör. 64k / 4k = 16)
  • şerit genişliği: stride * #-of-data-disks (ör. 4 disk RAID 5 3 veri diskidir; 16 * 3 = 48)

Gönderen Linux Wiki Raid . Farklı RAID seviyeleri ve disk sayısı için bu basit hesap makinesine de bakın .

İçin SSD'nin silme blok hizalama parametreler şunlardır:

  • fs blok boyutu (ör. 4096)
  • SSD silme bloğu boyutu (ör. 128k)
  • şerit genişliği: silme-blok-boyutu / fs-blok-boyutu (ör. 128k / 4k = 32)

Gönderen Theodore'un SSD yazı .

LVM uzantılarını hizalama

Potansiyel sorun LVM'nin 192 bin başlık oluşturmasıdır. Bu, 4k'ın bir katıdır (bu nedenle 4k blok disklerle ilgili bir sorun yoktur), ancak RAID şerit boyutunun (LVM bir RAID'de çalışıyorsa) veya SSD silme blok boyutunun (LVM SSD'de çalışıyorsa) birden fazla olmayabilir.

Geçici çözüm için Theodore'un gönderisine bakın .


@Marco Nasıl yani? İlki, IBM Developer Works için, hizalanmamış bölümleri kullanmak için yazma performansı cezası ve RAID'de bir kenar çubuğuna ilişkin bir karşılaştırma grafiği bile var. Tso'nun SSD hizalaması hakkındaki blog yazısı bunu yazdığımdan beri en az iki kez taşındı. Bağlantı tekrar güncellendi, ancak çalışmaya devam edeceğine dair bir garanti yok.
jg-faustus

SSD'ye alternatif bağlantı: SSD bölümlerini hizalama
jg-faustus

8

Bir arkadaşım, /dev/md1hiçbir şeyi bölmeden hemen mkfs.ex4 yapabileceğimi belirtti , bu yüzden bölümü sildim ve bunu yaptım ve şimdi biçimlendiriyor gibi görünüyor.


6

En kolayı bu yolu buluyorum

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

ya da alternatif bir kirli yöntem şöyle olur

(parted) mkpart primary ext4 1 -1

Ayrıştırılmış belgeler, ayrıştırmanın bölümleri otomatik olarak optimize etmeye çalışmasına izin vermek istiyorsa MiB veya GiB yerine MB ve GB kullanılmasını önerir.
Felipe Alvarez

1

Mkfs.ext4, RAID'inizdeki dosya sistemlerinin 64 KiB sınırında başlamasını istiyor gibi görünüyor. Tüm diski kullanırsanız, elbette 64 KiB'nin katı olan 0'dan başlar ...

Günümüzde çoğu bölümleme aracı varsayılan olarak varsayılan olarak 1 MiB sınırı kullanacaktır (fdisk muhtemelen kullanmaz).

Bunun nedeni, çoğu sabit disk ve SSD'nin cihazda mantıksal sektörlerden çok daha büyük fiziksel sektörler kullanmasıdır. Bunun sonucu olarak, diskten 512 baytlık mantıksal bir sektör okursanız, donanım aslında çok daha fazla miktarda veri okumalıdır.

Yazılım RAID cihazınızda benzer bir şey olur: üzerindeki veriler, varsayılan mdadm ayarlarıyla 64 KiB'lik "parçalar" halinde saklanır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.