mdadm ve 4k sektörleri (gelişmiş format)


10

Serverfault hakkında 4k sektör disklerinin hizalanması hakkında çok sayıda soru var, ancak bir şey benim için henüz net değil.

RAID1 + LVM'mi başarıyla hizaladım. Yaptığım şeylerden biri mdadm superblock sürüm 1.0'ı kullanıyordu (diskin sonunda süperbloğu depolayan).

Manpage şöyle diyor:

Farklı alt sürümler, süper bloğu cihazın sonunda (1.0 için), başlangıçta (1.1 için) veya 4K'dan (1.2 için) farklı konumlarda saklar. "1", "1.0" a eşdeğerdir. "varsayılan", "1.2" ye eşdeğerdir.

4k sektör sürücüleri için varsayılan 1.2 sürümü mü yapılıyor? Gördüğüm gibi değil, çünkü başlangıçtan itibaren 4k + süper bloğun uzunluğu çok sayıda 4k değil (süper blok yaklaşık 200 bayt uzunluğunda, doğru hatırlıyorsam).

Bu konuda herhangi bir fikir hoş geldiniz.

Düzenle:

Aşağıda mdadm süperblok 1.1 ve 1.2'nin 4 k hizalaması için olduğu cevaplanmıştır. Ben sadece bir cihaz baskını oluşturdum:

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

Sonra buna mantıksal bir birim ekledim:

vgcreate universe2 /dev/md4

Dizi 16 MB / sn hızda senkronize ediliyor:

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

Bu yüzden uygun şekilde hizalandığından şüpheliyim.

(diskler 1,5 TB WD EARS'tır. Masaüstü bilgisayarımda var ve yaklaşık 80 MB / s hızında senkronize oldular.)

Edit2:

İşte --examine çıktısı:

# 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)

Veri ofseti 2048 sektördür, bu 8 ile bölünebilir, bu yüzden biri iyi olduğunu düşünür. Hacim grubunun fiziksel boyutu 4 MiB'dir ve bu da 8 ile bölünebilir.

Başka bir düzenleme: bir uyum sorunu gibi görünmüyor; hdparm -t disklerden biri için çok düşük bir okuma hızı gösterdiğinden (30 MB / s). Başka bir şey yanlış.

Edit2: Cevabı bulduğumda bu yazıyı güncellemeyi asla hatırlamıyorum. Her şey güzel hizalanmış. Disklerden biri bozuldu. Görünüşe göre son bacağındaydı ve bu bile bir noktada kırıldı. Yeni bir disk sorunsuz çalıştı.

Yanıtlar:


13

Evet, 4k sektör hizalaması için yapılmıştır.

1.1 ve 1.2 süper bloklarla, süper bloğun ezilmemesi için her diskin başında yer ayrılır. Süperblok oluşturma kodu, bu ayrılmış alanı 4kB'nin bir katı olmaya zorlar. Tüm fiziksel okumalar , süper bloğun sonundan değil , bu ayrılmış alanın sonundan kaydırılır . Bu nedenle, 4kB'ye eşit olarak bölünen herhangi bir sektör boyutu için hizalama korunur.

Eğer ilgileniyorsanız, mdadm kaynak kodunun ( super1.c) kanıtı :

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

Ve bu data_offsetparametre , örneğin okuma yolundaki fiziksel okumaları dengelemek için çekirdekteki RAID1 kodu tarafından kullanılır :

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

1.1 ve 1.2 hem 4k hizalama için uygunsa, 1.2 sürümü ne işe yarar? Demek istediğim, neden superblock'un 4k'yi baştan başlatmasını isteyeyim?
Halfgaar

2
Böylece diskin başlatılması, önyükleme blokları için ayrılabilir ve diskin bir önyükleme diski olarak kullanılmasına izin verir.
Tom Shaw

Yazımı yeni güncelledim. Görünüşe göre, yeni dizim uygun şekilde hizalanmamış.
Halfgaar
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.