OSX ile ilgili dün buna benzer bir şey okuyordum ve dosya sisteminin sıkıştırılması - Temel olarak cevap sıkıştırmak istediğiniz şey etrafında dönüyor - bu örnekte "FAT" verileri hakkında konuşuyor; dosya yapıları, özellikleri, meta verileri vb. birlikte depolandığında yerden tasarruf etmek için sıkıştırılabilir ve her dosya için veri bulmak için her yerde baş aramaktan daha hızlı bir şekilde cpu'ya okunabilir ...
Ancak sıkıştırma yalnızca disk alanından tasarruf etmekle ilgili değildir. Ayrıca azaltılmış G / Ç gecikmesi ve bant genişliği için CPU döngülerinin alım satımına klasik bir örnektir. Geçtiğimiz birkaç on yılda, CPU performansı, disk performansının artmasından çok daha hızlı bir şekilde daha iyi hale geldi (ve kaynakları daha bol ve daha sonra daha fazla hesapladı). Modern sabit disk arama süreleri ve dönme gecikmeleri yine milisaniye cinsinden ölçülür. Bir milisaniyede, 2 GHz CPU iki milyon döngüden geçer. Ve sonra, elbette, dikkate alınması gereken gerçek veri aktarım süresi var.
İşletim sistemi ve donanım genelinde çeşitli önbellekleme seviyeleri, bu gecikmeleri gizlemek için güçlü bir şekilde çalışır. Ancak bu bitlerin bu önbellekleri doldurmak için bir noktada diskten çıkmaları gerekir. Sıkıştırma, daha az bitin aktarılması gerektiği anlamına gelir. Normal kullanımda modern çok çekirdekli bir Mac'te neredeyse komik CPU kaynakları göz önüne alındığında, sıkıştırılmış bir yükü diskten aktarmak ve içeriğini belleğe açmak için CPU'yu kullanmak için gereken toplam süre genellikle zamandan çok daha az olacaktır. verilerin sıkıştırılmamış biçimde aktarılması gerekir.
Bu, daha az veri aktarmanın potansiyel performans avantajlarını açıklar, ancak dosya içeriğini depolamak için genişletilmiş özniteliklerin kullanılması da işleri daha hızlı hale getirebilir. Her şeyin veri lokalitesi ile ilgisi vardır.
Bir sabit diski büyük miktarda veri aktarmaktan daha yavaşlatan bir şey varsa, kafalarını diskin bir bölümünden diğerine taşır. Her hareket, kafanın hareket etmeye başlaması, sonra durması, daha sonra istenen konuma doğru şekilde yerleştirildiğinden emin olunması, ardından dönen diskin istenen bitleri altına koymasını bekleyin. Bunların hepsi gerçek, fiziksel, hareketli parçalardır ve danslarını olduğu kadar hızlı ve verimli bir şekilde yapmaları şaşırtıcıdır, ancak fiziğin sınırları vardır. Bu hareketler, sabit diskler gibi dönel depolama için gerçek performans katilleridir.
HFS + birim biçimi, dosyalar hakkındaki tüm bilgilerini (meta veriler) diskteki iki birincil konumda depolar: dosya tarihlerini, izinleri, sahipliği ve diğer pek çok şeyi depolayan Katalog Dosyası ve "adlandırılmış çatalları depolayan Özellikler Dosyası" ."
HFS + 'daki genişletilmiş öznitelikler, Öznitelikler Dosyasında adlandırılmış çatallar olarak uygulanır. Ancak çok büyük olabilen kaynak çatallarının aksine (dosya sistemi tarafından desteklenen maksimum dosya boyutuna kadar), HFS + 'daki genişletilmiş öznitelikler, Öznitelikler Dosyasında "satır içi" olarak depolanır. Uygulamada, bu, öznitelik başına yaklaşık 128 baytlık bir sınır anlamına gelir. Ancak aynı zamanda, disk verisinin gerçek verileri almak için diskin başka bir bölümüne gitmesi gerekmediği anlamına gelir.
Tahmin edebileceğiniz gibi, Katalog ve Öznitelik dosyalarını oluşturan disk bloklarına sık sık erişilir ve bu nedenle çoğu yerde bir önbellekte olma olasılığı daha yüksektir. Tüm bunlar, B-ağacı yapılı Katalog ve Nitelikler dosyalarında hem meta verileri de dahil olmak üzere bir dosyanın eksiksiz bir şekilde depolanmasını genel bir performans kazanması için yapar. 25 bayta kadar balon yapan sekiz baytlık bir yük bile, normal veri depolama için ayırma bloğu boyutundan daha az olduğu ve tümü Nitelikler Dosyasındaki bir B-ağacı düğümü içine sığdığı sürece endişe verici değildir. İşletim sistemi yine de bütünüyle okumak zorundadır.
Snow Leopard'ın azaltılmış disk ayak izine (örneğin, gereksiz yerelleştirmelerin ve "designable.nib" dosyalarının kaldırılmasına) başka önemli katkılar da vardır, ancak HFS + sıkıştırması teknik olarak en ilginç olanıdır.
