LBA ve sektör büyüklüğü

LBA, sürücü 4K sektörlerle biçimlendirilmiş olsa bile sektörleri her zaman 512 bayt olarak belirtir mi? Çünkü bölüm kümelerini, 4K kümelerinin 4K sektörlerle aynı hizaya gelmesi için biçimlendirmeniz gerektiğini okudum. Disk 4K sektörlerle biçimlendirilmiş ancak LBA her 512 baytta atarsa, bu sorunun ortaya çıktığını varsayıyorum. Nedeni bu mu? Ayrıca, mantıksal sürücü geometrisinin fiziksel sürücü geometrisinden farklı olmasının nedeni - eski standartlarla geriye dönük uyumluluğu ve CHS ile sınırlamaları korumak için mi? Sürücü tarafından rapor edilen geometri doğru değilse, bölümlerin neden hala sektör 63'de başlatılması gerekir (bu artık her zaman doğru silindir değilse)?

Kümeler bölümün başlangıcı mı yoksa diskin başlangıcı mı?

• LBA, sürücü 4K sektörlerle biçimlendirilmiş olsa bile sektörleri her zaman 512 bayt olarak belirtir mi?

Evet, 512 baytlık sektörlerin münhasır hakimiyeti zamanlarında dünyada birçok kod yazıldı. Bu kod başka herhangi bir sektör boyutunu işleyemediğinden, BIOS / disk donanımı, gerçek sektör boyutundan bağımsız olarak her zaman 512 bayt sektörleri taklit eder. Aksi takdirde, işletim sistemlerinin% 95'i bu tür disklerden hiç önyükleme yapmazdı.

• Ayrıca, mantıksal sürücü geometrisinin fiziksel sürücü geometrisinden farklı olmasının nedeni - eski standartlarla geriye dönük uyumluluğu ve CHS ile sınırlamaları korumak için mi?

CHS adresleme sisteminde sınırlar vardır. 1 ≤ S ≤ 63, 0 ≤ H ≤ 255 (ve bazen 0 ≤ C ≤ 1023). Mantıksal geometrinin var olmasının ve fiziksel geometriden farklı olmasının nedeni budur.

• Sürücü tarafından rapor edilen geometri doğru değilse, bölümlerin neden hala sektör 63'de başlatılması gerekir (bu artık her zaman doğru silindir değilse)?

Windows Vista'dan beri FDISK, LBA sektörü 2048 (1M hizalaması) ile ilgili ilk bölümü oluşturur. Herhangi bir CHS koordinatı olabilir; artık önemli değil.

Windows XP ve önceki sürümlerde, ilk bölüm CHS sektöründe (C = 0, H = 1, S = 1) oluşturuldu ve bu genellikle LBA sektör 63 ile eşleşir (eğer bu diskin mantıksal geometrisinde parça başına 63 sektör varsa). Bazı USB flash sürücüler, parça başına 32 sanal sektörle mantıksal geometriye sahiptir, bu nedenle ilk bölüm onlar için LBA sektör 32'de başlar. Her durumda, tüm bunların gerçek disk geometrisi, performans nedenleri, vb. İle ilgisi yoktur - Vista / Windows 7'de sonlandırılmış saf bir gelenektir.

• Kümeler bölümün başlangıcıyla mı yoksa diskin başlangıcıyla mı hizalanmış?

Kümeler her zaman bölümün başlangıcı ile hizalanır. Bu nedenle, bölüm Vista öncesi oluşturulmuşsa FDISKve kendi kendine hizalanmamışsa, diskte yanlış hizalanmış olabilirler .

LBA'nın kendisi herhangi bir sektör boyutuna uygulanabilir, ancak PC'nin başlangıcından beri sabit disk sektörü boyutları 512 bayt olmuştur ve tüm donanım ve yazılımlar bu varsayımla sabit kodlanmıştır. Bu nedenle, yeni sistemlerin ve işletim sistemlerinin 4K sektörleri desteklemesini beklemek yerine, harici olarak 512 bayt sektör sürücüsü olarak görünecektir.

CHS, LBA48'in 2003 yılında piyasaya sürülmesinden bu yana öldü. CHS 128 GB ile sınırlıdır, bu nedenle bu boyuttan büyük her sürücü CHS'yi desteklemez (modern bir sürücüye bakın; etikette bir CHS değeri olmayacaktır) ). Tüm donanım ve işletim sistemlerinin güncellenmiş olması durumunda (Windows 98, LBA desteği ekledi).

CHS ile bile, fiziksel sürücü özellikleri CHS değerleriyle eşleşmedi. Cidden, hiçbir sabit disk 255 kafaya sahip değildi. Sürücünün denetleyicisi dahili olarak CHS değerlerini LBA'ya dönüştürür.

Bölümlerin sektör 63'te başlaması gerekmez - bu eski bir DOS sınırlamasıdır. DOS, bir bölümün bir silindir sınırını bölmemesini ve CHS'nin silindir için 63 sektörü olmasını istedi. Windows XP'ye kadar Microsoft, DOS ile uyumluluğu korumaya karar vermiştir (FAT32 bölümünde Windows 98, ME ve XP'yi çift önyükleme yapmak mümkün olmuştur). 4K sektörlere kadar, bununla ilgili bir sorun yoktu.

Son olarak, sorunuzu cevaplamak için: kümeler diskle değil bölümün başlangıcıyla hizalanır. Bu nedenle bölümünüzün bir sektör sınırına uygun şekilde hizalanması önemlidir.