Bunun doğru davranış olduğunu düşünüyorum. 4k diskler hala arabirim tarafında 512 Bayt sektörler bildiriyor. Her ne kadar sektörleri 4 k blok halinde ele alsalar da.
Jumper çoğu sürücüde sadece bir sektör değişikliğine olanak tanır. Çoğu sürücüde, sektör adresleme 1'e geçer. Bunun nedeni Winodws XP gibi 4k farkında olmayan işletim sistemidir. Anlamak için, Windows XP'nin sektör 63'te başlayan ilk bölümü oluşturduğunu bilmeniz gerekir (evet, bu yazım hatası değildir).
Çoğu durumda Windows, 4k ayırma birimleri (NTFS kümeleri) olan bir dosya sistemi kullanır. Bu nedenle, geleneksel bir sürücüden bir NTFS kümesini okuduğunuzda, sadece 8 fiziksel bloğu okumak zorunda olduğunu varsayabilirsiniz. Oldukça basit.
Şimdi sürücü 4k sektör boyutunu da kullanacak. İşletim sistemi hiçbir zaman 4k'den daha küçük kümeleri okumadığından bu tamamen iyidir, çünkü bu en küçük ayırma birimidir (format sırasında daha küçük FS kümelerini zorlamadığınız varsayılarak). Yazdığım gibi, sürücüler uyumluluk nedeniyle hala 512 Bayt sektörleri arayüz düzeyinde ortaya koyuyor. Ancak tek bir 512 Baytlık bloğu okursanız, sürücü dahili olarak yine de bir 4k sektörü okur ve daha sonra kablo arabirimi aracılığıyla yalnızca 512 Bayt göndermek için böler.
Peki sorun şimdi nerede? ###
Windows XP ile ilgili sorun, bölüm varsayılan olarak 63 bloğuna hizalanmış olmasıdır. Bu, NTSF kümelerinin fiziksel bloklara yanlış hizalanmasına neden olur. Bunu göstermek için küçük bir resim oluşturdum:
Windows XP'de resimde görebileceğiniz gibi, mantıksal küme fiziksel 4k bloklarla hizalanmamıştır. Sonuç olarak, Windows mantıksal bir NTFS kümesini okursa, sürücünün yalnızca bir değil iki blok okumasını gerektirir. Daha da kötüsü, tek bir NTFS kümesine ihtiyacınız varsa, iki sektörü okur ve yalnızca istenen verileri işletim sistemine geri döndürmek için bunları birleştirmek zorundadır.
Yazma işlemleri için daha da kötüdür. Bu durumda, sürücünün iki fiziksel 4k kesimi okuması ve her iki kesimi de diske geri kaydetmeden önce içeriğini yeni NTFS kümesinin içeriğiyle birleştirmesi gerekir. Bu, sürücünün üzerine yazarak HDD'deki sektörü değiştirmek yerine sürücünün 8k okuması, bir tamponda birleştirilmesi ve 8k yazması gerektiği anlamına gelir. Bu yazma işlemlerini çok yavaşlatır.
Gereksiz birleştirme HDD üreticilerini önlemek için Jumper aracılığıyla etkinleştirilebilen bir "uyumluluk" kesmek ekledi. Her 512 bayt sektör adresini 1 arttırır. Sonuç olarak, Windows tarafından oluşturulan ilk bölüm 64. sektörde başlar ve eşleme aşağıdaki gibi görünür:
Artık herhangi bir mantıksal 4k NTFS bloğunun okunması / yazılması, tam olarak bir fiziksel sektörü okuma / yazma ile sonuçlanır.
Tabii ki, 4k sektör sınırlarına hizalanmış bölümlerinizi oluşturursanız, bu geçici çözüm gerekli değildir. Örneğin Linux'ta fdiskbölümünüzün hangi blokta başlayacağını tanımlamak için kullanabilirsiniz . Burada 8 çarpı kullanmak iyi bir fikirdir.
Windows Vista'dan beri 2048 AFAIR sektöründeki ilk bölüme başlıyor. Yani bu sorun artık burada oluşmuyor.
UYARI : Hala jumper çözümünü Vista, Win7 veya Win2k8 R2 gibi 4k özellikli işletim sistemlerinde kullanıyorsanız, bu aslında sektör hizalamasını BREAK yapabilir. Bunun sebebi, diskin bir kez daha sektör adreslerini 1 artıracağı ve ilk bölümün 2049 sektörüyle aynı hizaya gelmesi ve bu da yine önemli performans düşüşüne neden olmasıdır.
Bu nedenle, sürücüyü bölümlere ayırmadan önce jumper'ı çıkardığınız 4k farkında bir işletim sistemi kullanıyorsanız emin olun. Özel durumunuzda, sürücüyü atlama teli çıkarılmış halde yeniden bölümlediğiniz sürece her şeyin iyi olması gerektiğini düşünüyorum. Sürücünün biçimlendirilmesinin sektör hizalaması ve 4k adresleme ile bir ilgisi yoktur. Biçim sırasında emin olmanız gereken tek şey, 2k NTFS kümeleri işletim sisteminden her HDD erişimi için tam bir 4k sektörü okuma gereksinimi doğuracağından, 4k'dan daha küçük küme boyutlarını kullanmamanızdır. Bu arada: Disk her NTFS okuma / yazma işlemi için yalnızca 2 sektörü okuyacağından, 8k NTFS kümelerinin kullanılması hala tamamdır.