SSD, Silme Bloğu Boyutu ve LVM: Ham cihazda PV, Hizalama


15

Yeni bir SSD takmak ve tüm cihazı LVM için PV olarak kullanmak istiyorum - başka bir deyişle: bu cihaza bir bölüm bile koymayı planlamıyorum. Bu nedenle, silme blokları üzerindeki bölümleri hizalamak gerekli değildir.

Soru (lar)

Giriş --dataalignmentyaparken silme bloğu boyutuna pvcreateve giriş yaparken silme bloğu boyutunun --physicalextentsizebir katına ayarlamak yeterli vgcreatemi?

Yani, SSD'min 1024k'lik bir silme bloğu boyutuna sahip olduğunu varsayarsak,

  • pvcreate --dataalignment 1024k /dev/ssd
  • vgcreate --physicalextentsize $(( x * 1024 ))k ...

Dikkate alınacak başka bir şey var mı?

Bu VG'de LV'lere ext4 dosya sistemleri koyacağımı varsayarsak, ext4 uzantılarını LVM-PE boyutuna hizalamak iyi bir fikir olurdu, değil mi? Bu nedenle ext4-extents, LVM-PE boyutuyla aynı boyutta mı yoksa katları mı olmalıdır?

Herhangi bir açıklama için teşekkürler!

Yanıtlar:


9

Evet, ayrıca MBR / PBR / GPT / MD / LVM'nin tüm disk üstü düzenini de kontrol ettim ve aynı sonuca vardım.

Sizin durumunuz için (ham diskte LVM), LVM-PE (fiziksel kapsam) pvcreate ile 1MB uyumluysa, ayırma boyutunu (1MB * N) koruduğunuz sürece tüm diğer veri tahsisinin hizalanacağından emin olabilirsiniz. .

Hem "vgcreate -s" hem de "lvcreate -L", birimsiz boyut olarak varsayılan değer olarak MB değeri olarak işlediğinden, pvcreate'ınızı düzgün bir şekilde yaptıktan sonra muhtemelen hizalamaya çok fazla dikkat etmeniz gerekmez. % / PE (lvcreate -l için) ve B (bayt) / S (512B - sektör her zaman LVM'de 512B'dir) / K (KB) (vgcreate -s ve lvcreate -L için) boyut vermediğinizden emin olun.

=== açıklama için eklendi ===

Bir takip olarak, bir SSD'nin tüm cihaz olarak 1024KB silme bloğu boyutu olabilirken, her dahili flaş çipinin silme bloğu boyutu / rw sayfa boyutu muhtemelen yaklaşık 32KB-128KB / 512B-8KB'dir.

Bu, her SSD'nin denetleyicisine bağlı olmasına rağmen, fazladan okuma-değiştirme-yazma döngüsü nedeniyle G / Ç cezası, muhtemelen yazınızı, her bir iç yonganın blok boyutunu silmek için hizalı tuttuğunuz sürece (32KB-128KB) misal. Tek bir yazma isteğinin yeterince büyük olmasını istiyorsunuz (= bir bütün olarak SSD'nin blok boyutunu sil), böylece tüm dahili yongaları / kanalları verimli bir şekilde sürerek daha iyi performans bekleyebilirsiniz.

Anladığım kadarıyla, 1024KB hizalaması, denetleyici yonga işlevi bir satıcıya göre değiştiğinden ve flash çipin spesifikasyonunun hızla değiştiği için sadece bir güvenlik önlemidir. İşletim sistemi düzeyinde yazma isteğinin büyük bir pakette (bu durumda 1024 KB) yapılması daha önemlidir.

Şimdi bunu söyledikten sonra, 1MB hizalanmış LVM bloğunda mkfs (8) yapmak dosya sistemi düzeyindeki veri / meta veriler için neredeyse kesinlikle 1MB hizalamayı bozacaktır. Çoğu dosya sistemi yalnızca 4KB hizalaması yapmaya özen gösterir, bu nedenle SSD'ler için mükemmel değildir (ancak IIRC, btrfs gibi son fs, dahili bitişik blok tahsis ederken 64KB + hizalamasını korumaya çalışır). Ancak birçok fs, RAID'den performans elde etmek için yazma işlemlerini birleştirme özelliğine sahiptir (ör: şerit boyutlu yapılandırma), böylece SSD'ye yazma isteğini en uygun hale getirmek için kullanılabilir.

İfademi gerçek verilerle desteklemek istiyorum, ancak bugünün SSD denetleyicisi çok akıllı olduğu ve hem hizalama boyutu hem de yazma boyutu "yeterince büyük" olduğunda performansta çok fazla bozulma göstermediğini kanıtlamak gerçekten zordu. Sadece hizalanmadığından emin olun (ne pahasına olursa olsun <4KB hizalamasından kaçının) ve çok küçük değil (1024 KB yeterince büyük).

Ayrıca, IO cezasını gerçekten önemsiyorsanız, cihaz önbelleğini devre dışı bırakarak ve senkronize edilmiş okuma-yazma-yeniden yazma testiyle karşılaştırmayı tekrar kontrol edin.


6

Anladığım kadarıyla, varsayılanlar zaten yeterince iyi. LVM otomatik olarak sysfs dışa aktarılan değerlere göre her şeyi hizalamaya çalışacağından --dataalignment seçeneği hakkında endişelenmeniz gerektiğini düşünmüyorum, lvm.conf'daki "data_alignment_detection" seçeneğine bakın:

# By default, the start of a PV's data area will be a multiple of
# the 'minimum_io_size' or 'optimal_io_size' exposed in sysfs.
# - minimum_io_size - the smallest request the device can perform
#   w/o incurring a read-modify-write penalty (e.g. MD's chunk size)
# - optimal_io_size - the device's preferred unit of receiving I/O
#   (e.g. MD's stripe width)
# minimum_io_size is used if optimal_io_size is undefined (0).
# If md_chunk_alignment is enabled, that detects the optimal_io_size.
# This setting takes precedence over md_chunk_alignment.
# 1 enables; 0 disables.
data_alignment_detection = 1

Ayrıca, varsayılan 4MB olduğundan vgcreate için fiziksel bir boyut belirtmek gerekli değildir.

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.