ÖZET
1TB dahili diski olan bir Dell Inspiron 17-5767 dizüstü bilgisayarım var Orijinal olarak gönderilen Windows 10'un tamamen kendine gelmesine ve kendilerine hükmetmesine izin verdim (bu benim oyun işletim sistemim). Ek olarak, mevcut ve gelecekteki Linux işletim sistemimi açacağım ve açacağım iki harici sürücüm var. Mevcut kurulumum aşağıdaki gibidir:
- USB 3.0 Bağlantı Noktası # 0: Seagate Genişletme + 931.5 GiB (1000204885504 bayt) Harici HDD / dev / sdb olarak tanındı
- şu anda bir tam boyutlu, boş ext4 bölümü barındırıyor, ancak bunu 12 bölümden oluşan optimum bir hizalanmış bölümleme şemasıyla değiştirmek için mücadele ediyorlar (hizalama ile mücadele noktası)
- USB 3.0 Bağlantı Noktası # 1: 238.5 GiB (256060514304 bayt) Samsung SSD 840 Pro / dev / sdc olarak tanınır
- Fedora LiveCD'nin kurucusu ("özel" seçeneğiyle) kullanılarak bölümlendi ve hem Fedora LXDE hem de Lubuntu linux dağıtımlarını paylaşılan bir takas alanı, paylaşılan kullanıcı alanı, ayrı kökler ve ayrı harici önyükleme bölümleri içeren tek bir LVM içinde barındırıyor dış burada, sadece LVM'de değil, aynı diskte başka bir yerde kendi ayrı birincil bölümlerinde kastediyorum)
- Bu sürücünün hem fiziksel hem de mantıksal blok boyutu 512'dir ve bölümün 'hizalama-kontrol opt x' yardımcı programına göre en iyi şekilde hizalanmış ve fdisk de hizalamadan memnun (herhangi bir yardımcı programdan hizalama şikayeti yok)
- UEFI BIOS dahiliden önce USB'den önyüklemeye çalışır, bu yüzden mevcut tüm seçeneklerimde ortaya çıkar
HEDEF
/ Dev / sdc on / dev / sdb sürücüsü ile olanları, ancak 5 linux dağıtımıyla olanları kopyalamaya çalışıyorum. Projemin bu yönünü ele aldım, çünkü deneyimli bir çok güçlüyüm. Ancak hedefimin diğer kısmı, / dev / sdb'deki bölümlememin en iyi şekilde eşitlenebilmesi için / dev / sdc örneğindeki gibi ve başımın belaya girdiği yer.
ÇEVRE
Şu anda nispeten yeni ve yükseltilmiş Fedora LXDE kurulumumdan çalışıyorum ve elde ettiğim sonuçlar Lubuntu'yu da nispeten yeni ve yükseltilmiş kurulumumda tamamen tekrar ediyor.
RAPORLANMIŞ DİSK PARAMETRELERİ
[root@frank ~]# cat /sys/class/block/sdb/queue/physical_block_size
4096
[root@frank ~]# cat /sys/class/block/sdb/queue/logical_block_size
512
[root@frank ~]# cat /sys/class/block/sdb/queue/minimum_io_size
4096
[root@frank ~]# cat /sys/class/block/sdb/queue/optimal_io_size
33553920
[root@frank ~]# cat /sys/class/block/sdb/alignment_offset
0
[root@frank ~]# fdisk -l /dev/sdb
Disk /dev/sdb: 931.5 GiB, 1000204885504 bytes, 1953525167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 9428D9DB-746C-40CA-B189-060F92A10E3C
Device Start End Sectors Size Type
/dev/sdb1 65535 1953467279 1953401745 931.5G Linux filesystem
Partition 1 does not start on physical sector boundary.
[root@frank ~]#
SORUN
Bu nedenle, fiziksel blok boyutunun raporlanmasına dayanarak, diskin diğer sürücü gibi 512b yerine 4k (gelişmiş format) olduğu, geriye dönük uyumluluk amaçları için 512b mantıksal bir sektör boyutu kullandığı görülüyor. GNU ayrımlı yardımcı programın 512 blok büyüklüğünü aldığını söyleyebilirim, çünkü optimum IO aralığını hesapladığında
(optimal_io_size + alignment_offset) / physical_block_size = optimal_sector_interval
ilk bölümü otomatik olarak başlatacağı yer olan 65535 değerine sahip olur ve hiza-kontrol alt yardımcı programının bir bölüm hizalamasını optimal olarak geçmesinin tek yolu, 65535'in bir katı ile başlarsa olur. Elde edilen sonuç, eğer fiziksel_iyosunu 4096 yerine 512 olarak kabul ediyorsanız,
(33553920 + 0) / 512 = 65535.
Bununla birlikte, bölümlenmiş 4096 blok boyutunu anlaşılır bir şekilde kullanamazsınız, çünkü o zaman denklem çalışacaktır.
(33553920 + 0) / 4096 = 8191.875.
Bu cevap, bir lise cebir öğretmenini tatmin edecektir, ancak belli bir değerin ayrı bir değer bekleyeceği bir sektör aralığı olarak bir anlam ifade etmemektedir (yani bir tamsayı!). Her durumda, bazıları 256MiB kadar küçük, GNU Partion'da mümkün olmayan yüzdeleri kullanarak yapmak mümkün olmayan 12 bölüm oluşturmak istediğim için ve uzun lafın kısası, sadece optimum hizalama için hizalama kontrollerini gerçekleştirebildim. Bölümlerimin arasına yapıştığım ve bölümlerimin 65535s aralıklarla başladığından emin olmak için kendim modüler aritmetik yapıyorum. Araştırmamdan yola çıkarak, bölümlerimin de bu aralıklarla sona ermesini sağlamanın önemli olduğunu düşünmedim ve bu nedenle bölümlerimin çoğu arasında boşluklar kaldı (açıkçası 65535'ten büyük değil).
Bir kez daha, bölümüm sonucumun en uygun şekilde hizalandığını ve fiziksel blok büyüklüğünün 4096 yerine 512 olarak değerlendirildiğini düşünüyordu. Fakat ayrıldıktan ve 'fdisk -l / dev / sdb' bölümünden ayrıldıktan ve çalışmadan sonra çıktının içine girdim:
Partition 1 does not start on physical sector boundary.
Partition 2 does not start on physical sector boundary.
Partition 3 does not start on physical sector boundary.
Partition 4 does not start on physical sector boundary.
Partition 5 does not start on physical sector boundary.
Partition 6 does not start on physical sector boundary.
Partition 7 does not start on physical sector boundary.
Partition 8 does not start on physical sector boundary.
Partition 9 does not start on physical sector boundary.
Partition 10 does not start on physical sector boundary.
Partition 11 does not start on physical sector boundary.
Partition 12 does not start on physical sector boundary.
Öyleyse, ayrılanın sevdiği şey fdisk değil. Daha sonra gParted'i bölümlendirme şemasını tekrar yapmak için kullandım, birim büyüklüğü olarak 1 MiB kullanmasına izin verdim ve ilk disk bölümümü 2048'lerde, diğer diskimde (/ dev / sdc) gördüğünüz gibi başlattı. fdisk daha sonra mutlu oldu ve sektör uyumu konusunda şikayet etmekten vazgeçti, ancak GNU ayrıldı ve minimum mod için geçse de, optimum mod için hiza-kontrol testlerinde başarısız oldu.
Bununla birlikte, her iki durumda da, mkswap'ın (/ LV / sdb11 üzerine yerleştirdiğim LVM içinde bir takas hacmi oluşturduğum) bana şu uyarıyı verdiğini öğrendim:
[root@frank ~]# mkswap /dev/strange_quark_experimental/swap
mkswap: warning: /dev/strange_quark_experimental/swap is misaligned
Böylece, mkswap, disk bölümünün en uygun hizalanmış mı yoksa minimum hizalanmış mı olduğunu düşünerek takas hacmimin yanlış hizalanmış olduğunu ve mkswap da fdisk'in hizalama konusunda mutlu olup olmadığını takas hacminin yanlış hizalandığını bulur.
TEORİLERİ
Bütün bunlar beni, en az bir disk raporlama veya bölümleme programından gelen uyarıları görmezden gelmem gerektiği izlenimini uyandırıyor, ama hangisinden emin değilim. Ayrıca, HDD içeren USB uyumlu muhafaza, sektör parametrelerinden en az birini yanlış rapor ediyor olabileceğinden, tüm raporlamanın başlaması güvenilmezdir. Örneğin, belki de bir AF sürücüsü değil mi? Ya da belki de optimal G / Ç boyutu yanlış bildiriliyor. Ya da belki ikisi? Ve güven bana, bunun bir PEBKAC olayı olabileceğini de düşündüm, çünkü bölümleri 4k'lik bir sürücüde nasıl hizalayacağımızla ilgili bir şeyi yanlış anlıyor olabilirim. Emin değilim.
Ne olursa olsun, bölümlerimin en uygun hizada olduğuna ve mkswap olduğuna ya da en azından gerçekten en çok güvenmem gereken yardımcı programları, uyum konusunda şikayet etmekten vazgeçtiğime inanıyorum.
YARDIM ET
Lütfen neden ayrılmadığımı ve diğer disk yardımcı programlarını minimum hizalamadan başka bir şey üzerinde anlaşamadığımı anlamama yardımcı olun (yalnızca gParted veya gdisk ile bölümlendirirken elde edilebilir) ve lütfen gerçekten çok fazla endişe duymamın gerekip gerekmediğini söyleyin performans veya disk sağlığında çok önemli bir fark yoksa daha fazla zaman kaybetmeyeceğim için benim durumumda minimum hizalamaya göre optimum hizalamanın avantajları hakkında. Aksi takdirde, diskimin gelişmiş format avantajlarından tam olarak yararlanabilmek isterim.