“Boyut” ile “Diskteki Boyut” arasında neden bu kadar büyük bir fark var?

Aşağıda görebileceğiniz gibi, aralarında çok fark var Boyutu ve diskin üzerindeki Boyutu benim klasöründe alanlar. Neden?

Bunu biliyorum Disk üzerindeki boyut biraz daha olmalı Boyutu nedeniyle Windows ayırma birimlerinin, ama neden kadar fark olduğunu? Çok sayıda dosya yüzünden olabilir mi?

BTW, bu klasör Android telefonumun SD kartında. Bunun içinde haritalar uygulamam önbelleğe alınmış haritaları saklar ve uygulama haritasını Google Haritalar'dan alır.

^{Burada FAT / FAT32 dosya sistemini kullandığınızı varsayacağım, çünkü bunun bir SD kart olduğunu söylüyorsunuz. NTFS ve exFAT, tahsis birimleri bakımından benzer şekilde davranır. Diğer dosya sistemleri farklı olabilir, ancak yine de Windows'ta desteklenmiyorlar.}

Çok sayıda küçük dosyanız varsa, bu kesinlikle mümkündür. Bunu düşün:

• 50.000 dosya.

• FAT32 için maksimum olan 32 kB küme boyutu (ayırma birimi)

Tamam, şimdi alınan minimum alan 50,000 * 32,000 = 1,6 GB'dir (matematiği basitleştirmek için SI öneklerini kullanarak, ikili değil). Her bir dosyanın diskte aldığı alan her zaman ayırma birimi boyutunun bir katıdır - ve burada her dosyanın boşa harcanan (boşa harcanan) bir alan içine sığacak kadar küçük olduğunu varsayıyoruz.

Her bir dosya ortalama 2 KB ise, toplam 100 MB alırsınız - ancak tahsis birim büyüklüğü nedeniyle ortalama olarak 15x (dosya başına 30 KB) harcıyorsunuz.

Derinlemesine açıklama

Bu neden oluyor? Peki, FAT32 dosya sisteminin her bir dosyanın bulunduğu yeri izlemesi gerekir. Her bir baytın bir listesini tutacak olsaydı, tablo (bir adres defteri gibi) verilerle aynı hızda büyür ve boşa harcardı. Bu yüzden yaptıkları şey, "küme boyutu" olarak da bilinen "ayırma birimleri" ni kullanmaktır. Birim bu ayırma birimlerine ayrılmıştır ve dosya sistemi söz konusu olduğunda alt bölümlere bölünemezler - bunlar ele alabileceği en küçük bloklardır. Tıpkı bir ev numaranız gibi, ancak postaneniz kaç tane yatak odasına sahip olduğunuzu veya içlerinde kimin yaşadığını umursamıyor.

Peki, çok küçük bir dosyanız varsa ne olacak? Peki, dosya sistemi 0 kB, 2 kB veya 15 kB olsa bile umursamıyor, elinden geldiğince az yer verecek - yukarıdaki örnekte, bu 32 kB. Dosyanız bu alanın yalnızca küçük bir kısmını kullanıyor ve geri kalanı temelde boşa harcanıyor, ancak hala dosyaya ait - boş bıraktığınız bir yatak odası gibi.

Neden farklı tahsisat birimleri var? Eh, daha büyük bir masaya sahip olmak (adres defteri, örneğin, John'un 123 Sahte Sokak, 124 Sahte Sokak, 666 Şeytan Şeridi, vb. Bir evin sahibi olduğunu söylemek gibi) veya her birimde (evde) boşa harcanan bir travma haline gelir. Daha büyük dosyalarınız varsa, daha büyük ayırma birimleri kullanmak daha mantıklıdır - çünkü bir dosya diğerlerinin tümü doluncaya kadar yeni bir birim (ev) alamaz. Çok sayıda küçük dosyanız varsa, yine de büyük bir masaya (adres defteri) sahip olacaksınız, bu yüzden onlara küçük birimler (evler) de verebilirsiniz.

Büyük tahsis birimleri, genel kural olarak, çok sayıda küçük dosyanız varsa, çok fazla alan israf edecektir. Genel kullanım için 4 kB'nin üstüne çıkmak için genellikle iyi bir neden yoktur.

Parçalanma?

Parçalanma gelince, parçalanma bu şekilde yer israf etmemelidir. Büyük dosyalar parçalanabilir, yani birden fazla tahsis birimine bölünebilir, ancak her biri bir sonrakine başlamadan önce doldurulmalıdır. Birleştirme, ayırma tablolarında küçük bir alan kazandırabilir, ancak bu sizin sorununuz değil.

Olası çözümler

Gibi gladiator2345 önerdi , bu noktada tek gerçek seçenek onunla yaşamak veya daha küçük yerleşim birimleri ile yeniden biçimlendirmek için vardır.

Kartınız, masa boyutunda daha küçük bir limite sahip olan ve bu nedenle daha büyük bir birime hitap etmek için (32 kB tahsis birimleriyle 2 GB üst limiti olan) daha büyük tahsis birimleri gerektiren FAT16'da formatlanmış olabilir. Kaynak Braiam'ın izniyle . Bu durumda, yine de FAT32 olarak güvenle formatlanabilmelisiniz.

Bu, tek bir dosya halinde sıkıştırmanın / arşivlemenin yardımcı olabileceği durumlardan biridir. Ne Bob onun cevabını sözü doğrudur ama çözüm başka cevaplar da anlaşılacağı gibi diski reformating daha kolay olabilir. Dizini sıkıştırır veya arşivlerseniz (zip, tar veya başka bir yöntem kullanarak), dosya sistemi birkaç küçük dosya yerine tek bir büyük dosyanız olduğunu görür. Sıkıştırmadan bile geri alanın 1,4 GiB'sini geri alacaksınız çünkü tüm bu "küçük dosyalar" tek bir büyük dosya olarak sayılacak.

Bunun içinde haritalar uygulamam önbelleğe alınmış haritaları saklar ve uygulama haritasını Google Haritalar'dan alır.

Belki bir arşiv veya birden fazla dosya yerine bir veritabanı kullanmak için geliştirici ile konuşmalısınız. Bu muhtemelen diskin daha az parçalanmasına da yardımcı olacak ve özellikle bir NAND flash sürücüsü ise mutlaka yerden tasarruf sağlayacaktır. 100 MB yük / faydalı verinin 1,4 GB olduğu saçma durumu açıklarsanız, verilerin nasıl depolandığı konusunda yanlış bir şey var ve geliştiriciler daha iyi bir çözüm getirmeli.

Herhangi birinin bu sorunla karşı karşıya kalması durumunda, diskteki dosya boyutunda / alandaki büyük farklılığı görmenin başka bir nedeninin, alternatif veri akışlarının (ADS) kullanılması olduğunu bilmek faydalı olabilir.

Bu sadece benim bilgime NTFS için geçerlidir. ADS, hem meşru hem de meşru kullanımlarla tanınır:

• Internet'ten indirilen bir dosyayı etiketlemek için
• meta verileri depolamak için (Microsoft, bir dosyanın türünü belirlemek için dosya uzantısını kullanmamak gibi Apple işletim sisteminin bazı özelliklerini dahil etmek istedi)
• Bir malware bağlamında veri veya kod gizlemek için .

ADS basitçe: herhangi bir NTFS dosyası birden fazla veri akışına sahip olabilir ("alt dosyaları" anlayın). Biri, Windows Gezgini ve diğer Windows araçları tarafından kullanılan ana akış olup, bir dosyanın olağan içeriğini tutar. Alternatif veri akışları, tam olarak ana akış olarak başka bilgiler içerebilir, ancak bunlar doğrudan Windows araçları tarafından ele alınamaz (özellikle Explorer, ADS'nin boyutuna bakılmaksızın ana akış boyutuna eşit olarak dosya boyutunu görüntüler), ADS'yi yazmak, okumak ve bulmak için özel araçlar veya kod kullanmanız gerekir.

Asıl nokta, gözlenen büyük dosya boyutu farklılığı durumunda, ADS olasılığını ve gizli kötü amaçlı yazılımın göz ardı etmemesidir.

Başka bağlantı .

Güvenli bir şekilde ADS ile deneme yapmak için bunu DOS / CMD düzeyinde deneyin ...

Bir dosyanın içeriğini oluşturun ve C'nin kök dizininde gösterin:

C:\> echo The main data stream> test.txt
C:\> type test.txt

Sonuç:

C:\> The main data stream

Şimdi aynı yöntemle bir ADS ekleyin, sadece dosya adına ek olarak ADS adını belirtin:

C:\> echo The secret message> test.txt:secret

Dosyadaki gizli mesajı gizlediniz. Explorer’daki dosya boyutunun ADS "sırrı" na bayt eklediğimiz halde değişmediğini unutmayın.

ADS içeriğini görüntülemeye çalışın:

C:\> type test.txt:secret

Sonuç:

The filename, directory name, or volume label syntax is incorrect.

CMD type, ADS'nin içeriğini görüntüleyemiyor. Bunun yerine Not Defteri kullanacağız:

notepad test.txt:secret

Not Defteri'nde ADS'nin içeriğini görebiliriz:

The secret message

Masum bir metin dosyasının ADS'sinde tam bir çalıştırılabilir dosyayı da gizleyebilir ve istediğiniz zaman çalıştırabilirsiniz. Servet bilgisayar korsanlarına zarar vermez :-)

Sorun, küme boyutundan kaynaklanıyor olabilir.

Microsoft'a göre :

Birimdeki dosyalar veya klasörler için NTFS sıkıştırması kullanmıyorsanız, SIZE ve SIZE ON DISK arasındaki fark, gerekenden daha büyük bir küme boyutundan dolayı boşa harcanır. SIZE ON DISK değerinin SIZE değerine mümkün olduğu kadar yakın olması için optimal bir küme boyutu kullanmaya çalışmalısınız. SIZE ON DISK ve SIZE değeri arasındaki aşırı tutarsızlık, varsayılan küme boyutunun, birime kaydettiğiniz ortalama dosya boyutu için çok büyük olduğunu ve azaltılması gerektiğini gösterir. Bu yalnızca birimi yedekleyerek ve ardından uygun ayırma boyutunu belirtmek için format komutunu ve / a anahtarını kullanarak birimi yeniden biçimlendirerek yapılabilir: IE: format D: /a:2048 (Bu örnek 2 KB'lik bir küme boyutu kullanır).

Sürücünüzü daha küçük küme boyutuyla biçimlendirmeyi deneyin.

Diskinizi daha küçük bir küme boyutunda yeniden biçimlendirmeyi öneren birçok insan görüyorum. Bu bir SD kart olduğundan, birçok üreticinin NAND'ın küme boyutuna uyacak şekilde kartı önerilen küme boyutuna önceden biçimlendirdiğini unutmayın (her ikisini de senkronize tutmak en iyi okuma / yazma performansı ve aşınmayı azaltmak için çok önemlidir)

NAND'ın küme boyutunu değiştiremezsiniz (SD kartınızın donanımının fiziksel bir özelliğidir).

Öncelikle rapor probleminin bozuk bir dosya sistemi içerisinde olmadığından emin olmak için önce SD kartınızdaki scandisk / chkdsk komutunu çalıştırın.

İkincisi, hatayı Google Map devs’e rapor etmenizi öneririm, çünkü burada suçlayacaklardı. Üstün bir depolama yöntemi kullanıyor olmalılar. Bunun düzeltilmesi, uygulamanın daha az G / Ç ve dosya sisteminin sürücü etkinliği nedeniyle birçok cihazda daha hızlı çalışmasını sağlamalıdır.

Bu, birçok dosya sistemiyle ilgili genel bir sorundur. Burada işte iki faktör vardır, bir dosya sisteminin mantıksal birimler ve depolama ortamının fiziksel kısıtlamaları başına işleyebileceği maksimum "blok" sayısı. Herhangi bir bloğa yalnızca 1 dosya atanabilir (dosyalar genellikle ihtiyaç duyduğu kadar blok alır). Bu nedenle, 64 baytlık bir metin dosyası, bulunduğu dosya sisteminin blok boyutuna bağlı olarak genellikle 4k'dan 32k'ya kadar her şeyi alabilir.

Bunu düşünmenin bir yolu, dosya sistemindeki her bir bloğu bir kutu ve dosya sistemini bir oda olarak düşünmektir. Tüm kutularınız aynı büyüklüktedir ve bir odaya toplayabildiğiniz kadar sığmaya çalışırsınız. Hepsine daha fazla yer kalacak şekilde yerleştirirseniz, odanın tamamen kutularla dolu olması için daha büyük kutular almanız gerekir.

Eşyaları kutulara koymanın kurallarından biri, ilişkisiz iki şeyi kutuya koyamazsınız. Aynı belgenin bir parçası olmak zorundalar. Öyleyse bir sayfa metin yazacak olsaydım, kendine ait bir kutusu olurdu. Yazılan metnim çok fazla sayfa içeriyorsa, hepsini bir kutuya sığdıramazsam, başka bir kutu bulur ve yerine sayfalar koymaya devam eder, tüm sayfalarımı dosyalayana kadar tekrar ederdim. Ayrıca bu belge için kullandığım kutuları ve sırayla okumak için kutuların sırasını da yazdım.

Kutuları nasıl düzenleyeceğime bağlı olarak, tezahürümde yalnızca belirli sayıda kutu için yeterli yer olabilir. Bu yüzden doldurmak için büyük bir odam olsaydı, ancak sadece az sayıda kutuyu oda büyüklüğüne ulaşmak için çok büyük kutular kullanmak zorunda kalırdım.

Bu durumda, bir sayfamda belge hala tek bir kutuyu işgal eder, başka bir şey paylaşmaz.

Aynı durumlar çeşitli depolama çözümleri arasında da geçerlidir. FAT32, günümüzün büyük sabit disklerinde yalnızca düşük sayıda "kutu" olarak kabul edilenleri yönetebilir, bu nedenle bunu telafi etmek için çok büyük "kutular" ile biter.

Küme boyutlarının yanı sıra, aşağıdaki koşullar nedeniyle bir tutarsızlığa da sahip olabilirsiniz:

• Sıkıştırılmış veya şifrelenmiş dosyalar, mantıksal dosya boyutundan farklı bir alan kullanabilir.
• Bağlantılı dosyalar n sayısını, mantıksal dosya boyutu için dosyanın boyutunun çarpı çarpı sayısını bildirir , ancak kullanılan fiziksel alan genellikle daha azdır.

Wikipedia'daki Block Suballocation girişine bir göz atmalısınız. Bu tam olarak size olan şey. Tail Packaging destekli bir dosya sistemi kullanmak, tahsis kümesinin boyutunu değiştirmenin yanı sıra bu sorun için bir dosya sistemi düzeyinde bir çözümdür.

Hepsinin diski yeniden biçimlendirmeye ihtiyaç duyması sakıncalı.

Bazı durumlarda bu dosyaları yalnızca bir arşive depolamak sorunu çözecektir (ve küçük dosyalar da dosyaların sonunda yer kaybetmeyi bırakmanın yanı sıra sıkıştırılır). Bu, dekompresyon için biraz zaman harcamayı zorlaştırmaktadır.

Belirli bir uygulama ile ilgili sorun nedeniyle bu kadar çok küçük dosyanız varsa, başka bir yöntem kullanarak yazılım verilerinizi (bir veritabanında olabilir) depolamak mümkündür. Ama elbette programcılar için bir çözümdür, son kullanıcılar için değil.

http://en.wikipedia.org/wiki/Tail_packing

Windows 10'daki büyük dosya boyutu tutarsızlıklarını tek bir dosyada belirttim, ancak SAME dosyasının özelliklerine aynı konumdan (bir ağ sürücüsü) bakarsam, Windows XP'de büyük farklılıklar yok; Beklediğiniz gibi sadece küçük bir fark. Windows 10'da bir hata olduğunu düşünüyorum. 449MB'lık bir dosya muhtemelen Windows 10'un söylediği 3.99GB'ı almıyor.