Windows 8 Birleştiricisi?

Görünüşe göre Windows 8'in defragkomutunda bazı yeni seçenekler var:

/K Belirtilen birimlerde levha konsolidasyonu gerçekleştirin.

Bunun İngilizcede ne anlama geldiğini bilen var mı?

Bu PDF'nin yeni NTFS özellikleriyle birlikte bunun bir açıklaması var gibi görünüyor.

Diyor ki:

• Döşeme Konsolidasyonu

  • Tahsis edilen döşeme sayısını en aza indirmek için dosyaları etkili bir şekilde birleştirir

  • Döşeme, ince bir tedarik edilen hacimde tahsis birimidir

  • Şu IOCTL_STORAGE_QUERY_PROPERTYmülk kimliğini istemek için destek gerektirir :StorageDeviceLBProvisioningProperty

    • Birimin slab boyutunu alır

Windows 8'in birleştiricisi bağlamında bunun ne anlama geldiğini açıklayan hiçbir şey bulamadım. Ancak "döşeme konsolidasyonu" genellikle aynı tahsis boyutuna yuvarlanan nesnelerin birlikte yerleştirilmesi için hareketli nesneleri ifade eder.

Bunu yapmanın yararı genellikle oldukça azdır. Ancak, çok sayıda küçük nesneye erişildiğinde ortalama arama süresini azaltma eğilimindedir.

Aslında, ortalama arama süresini azaltmak için aynı boyuttaki birçok dosyanın tahsisini ayarlamak için levhaların yapıldığını sanmıyorum.

Benim düşüncem, hacim üzerinde yer ayırmaları gerektiğinde paralel iş parçacıkları tarafından çok fazla eşzamanlı erişime neden olacak büyük hacimlerdeki ayırma gecikmesini azaltmak için kullanıldığından, bu, birim ayırmanın aynı bölümüne bir kilit koyacağından bitmap. Büyük bitmap'leri işlemekten kaçınmak için, bit cinsinden boyutu aynı bitmap fragmanını kullanan diskteki tartışmalı alanları temsil eden "enlemelere" bölünebilir (en az 1 veya daha fazla kümeyi işgal eder; 4KB ise küme boyutunuz varsa, bitmap içindeki kümesi 4K * 8 = 32K ayrılabilir kümeler, yani 128 MB os depolama; bir birimdeki gerçek döşeme boyutu 33 ile 64 arasında ayarlanmıştır, bu da yaklaşık 33 eşzamanlı iş parçacığının birbirlerini engellemeden distmap üzerinde boşluk ayırmasına olanak tanır)

Bu nedenle, levhalar, kilidini açmadan ve başka bir levhayı denemeden önce veya mevcut levhaya daha küçük miktarlar tahsis etmeye çalışarak, çok sayıda dosya oluşturan bir iş parçacığının çoğunlukla kendi plakasında yapacağını varsayarak birimdeki alan tahsisini hızlandırmak için kullanılır. başka bir kullanılabilir kilitli olmayan döşeme ve daha sonra şu anda başka bir iş parçacığı tarafından kullanılan döşeme için bir engelleme erişim elde etmeye çalışıyorum.

Bu, diskte ayırmanın neden birime "yayıldığını" açıklar. Aynı zamanda, NTFS'deki MFT'nin, hacmi kullanan birçok iş parçacığı arasında ciddi kilitleri önlediğinden, diğer levhalara ait en az 2 parçaya neden sahip olduğunu açıklar. MFT'yi birleştirebilirsiniz, ancak eşzamanlı ayırmalar için NTFS biriminde engelleme G / Ç gerçekleştirmekten kaçınması gereken "ayrılmış alanında" en az bir parça kalır).

Geçmişte, NTFS hacmi birden fazla levhada alt bölümlere ayrılmamıştı ve çekirdekte G / Ç tamamlanmasını bekleyen çok sayıda iş parçacığı engelleme ve çok fazla iş parçacığı anahtarı ile büyük bir performans cezası vardı (bitmap'te ayırma aslında son derece aşırı olsa bile) hızlıdır ve bitmap'in ilginç kısmının çoğu bellekte önbelleğe alındığı için nanosaniye alır). Birimlerdeki yazılar daha sonra temizlendiğinde ve günlüğe kaydedildiğinde, günlükte ayırma nedeniyle oluşan başka bir kilit daha vardır, bu nedenle günlük artık birimde ayrı bir levha kullanır (mümkünse).

Ancak NTFS'nin belirli boyutlardaki dosyalara herhangi bir levha ayırdığını düşünmüyorum. Veri kaldırıldığında ve tahsis edilen boyutları bir miktar eşiğin altına düştüğünde ve bu tür iki levha birleştirildiğinde, NTFS, plakaları hafifçe birleştirir.

Döşeme boyutları hakkında bilgi alabilirsiniz:

fsutil fsinfo ntfsinfo c:

Açıkça, levhalar performans için ayarlanan parametrelerdir. Ancak birçok üçüncü taraf birleştirme aracı bu ayarı yok sayar ve en uygun yerleşimi kullanmaz. İdeal olarak, kütükler yeniden tahsis edilmeyen ve sabit kalması gereken dosya ve dizinlerle dolu olmadıkça, birimin her döşemesinde bir miktar boş alan olmalıdır. Sürekli olarak oluşturulan ve geri dönüştürülen birçok küçük geçici dosya ve işlem için, bunları eşzamanlı iş parçacıklarının sayısına bağlı olarak yeterli döşemeye yerleştirmeniz ve birim bir sabit disk veya RAID dizisi (SSD'de önemli değildir).

Döşemeler, uzak dosya sistemleri için de yararlı olabilir, ancak en uygun boyutlarının tahmin edilmesi zordur. Diğer taraftaki levhalar, hiyerarşik sanallaştırılmış hacimlerin farklı hacimleri için çok küçüktür ve çok farklı bir yerleşim stratejisi vardır, tahsisin sanal olduğu ve farklı fiziksel yerlere yeniden eşleştirildiği verilir.

Kayıt defterinde aşağıdaki ayar parametreleri hakkında Microsoft'tan hala bilgiye ihtiyacımız var:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfrg\SlabifyFunction]
MinimumReclaimSlabsMB      = REG_DWORD: 10240
MinimumReclaimSlabsPercent = REG_DWORD: 10
SlabEvictUpperBoundKB      = REG_DWORD: 204800
SlabEvictUpperBoundPercent = REG_DWORD: 20

Microsoft'un yerleşim stratejilerini değiştirmeyi düşündüğü ve zamanla değiştirebileceği için bunların amaçsız belgelenmediğini düşünüyorum. API tarafından maruz kalmazlar, kanıtlarını yalnızca kayıt defterinde ve NTFS sürücüsünün dahili kaynak kodu uygulamasında bulabilirsiniz.

Bildiğimiz tek şey, levhaların DEFRAG.EXE komut satırı aracının "/ K" parametresi tarafından kısa bir süre açıkta tutulmasıdır. Ancak, / K optimizasyonunun Windows'un ilk kurulumundan sonra (6 yeniden başlatma ve ölçümden sonra Bootvis optimizasyonu yapılmadan önce) büyük performans kazançları sağladığını gözlemlemek kolaydır. SSD'lerde düzeltme ile ilgili / L parametreleri de vardır.