Mengapa ada perbedaan besar antara "Ukuran" dan "Ukuran pada disk"?

Seperti yang Anda lihat di bawah, ada begitu banyak perbedaan antara Ukuran dan Ukuran pada bidang disk di folder saya. Mengapa demikian?

Saya tahu bahwa Ukuran pada disk harus sedikit lebih dari Ukuran karena unit alokasi di Windows, tetapi mengapa banyak perbedaan? Mungkinkah itu karena banyaknya file?

BTW, folder ini ada di kartu SD ponsel Android saya. Di dalam ini, aplikasi peta saya menyimpan peta yang di-cache dan aplikasi mendapatkan peta dari Google Maps.

^{Saya akan berasumsi bahwa Anda menggunakan sistem file FAT / FAT32 di sini, karena Anda menyebutkan ini adalah kartu SD. NTFS dan exFAT berperilaku serupa berkaitan dengan unit alokasi. Sistem file lain mungkin berbeda, tetapi mereka tidak didukung pada Windows.}

Jika Anda memiliki banyak file kecil, ini tentu saja mungkin. Pertimbangkan ini:

• 50.000 file.

• Ukuran cluster 32 kB (unit alokasi), yang merupakan maks untuk FAT32

Ok, sekarang ruang minimum yang diambil adalah 50.000 * 32.000 = 1,6 GB (menggunakan awalan SI, bukan biner, untuk menyederhanakan matematika). Ruang setiap file pada disk selalu merupakan kelipatan dari ukuran unit alokasi - dan di sini kami mengasumsikan setiap file sebenarnya cukup kecil untuk muat dalam satu unit, dengan beberapa ruang (terbuang) tersisa.

Jika setiap file rata-rata 2 kB, Anda akan mendapatkan sekitar 100 MB total - tetapi Anda juga menyia-nyiakan 15x itu (30 kB per file) rata-rata karena ukuran unit alokasi.

Penjelasan mendalam

Mengapa ini terjadi? Nah, sistem file FAT32 perlu melacak di mana setiap file disimpan. Jika ingin menyimpan daftar setiap byte tunggal, tabel (seperti buku alamat) akan tumbuh pada kecepatan yang sama dengan data - dan menghabiskan banyak ruang. Jadi apa yang mereka lakukan adalah menggunakan "unit alokasi", juga dikenal sebagai "ukuran cluster". Volume dibagi ke dalam unit-unit alokasi ini, dan sejauh menyangkut filesystem, mereka tidak dapat dibagi lagi - itu adalah blok terkecil yang dapat dialaminya. Sama seperti Anda memiliki nomor rumah, tetapi tukang pos Anda tidak peduli berapa banyak kamar tidur Anda atau yang tinggal di dalamnya.

Jadi apa yang terjadi jika Anda memiliki file yang sangat kecil? Nah, sistem file tidak peduli apakah file tersebut 0 kB, 2 kB atau bahkan 15 kB, itu akan memberikan ruang paling sedikit yang bisa - dalam contoh di atas, itu adalah 32 kB. File Anda hanya menggunakan sedikit ruang ini, dan sisanya pada dasarnya sia-sia, tetapi masih milik file - seperti kamar tidur yang Anda tinggalkan kosong.

Mengapa ada ukuran unit alokasi yang berbeda? Nah, itu menjadi tradeoff antara memiliki meja yang lebih besar (buku alamat, misalnya mengatakan John memiliki rumah di 123 Fake Street, 124 Fake Street, 666 Satan Lane, dll.), Atau lebih banyak ruang kosong di setiap unit (rumah). Jika Anda memiliki file yang lebih besar, lebih masuk akal untuk menggunakan unit alokasi yang lebih besar - karena file tidak mendapatkan unit baru (rumah) sampai semua yang lain terisi. Jika Anda memiliki banyak file kecil, Anda akan memiliki tabel besar (buku alamat) jadi mungkin juga memberi mereka unit kecil (rumah).

Unit alokasi besar, sebagai aturan umum, akan menghabiskan banyak ruang jika Anda memiliki banyak file kecil. Biasanya tidak ada alasan yang baik untuk menggunakan di atas 4 kB untuk penggunaan umum.

Fragmentasi?

Adapun fragmentasi, fragmentasi seharusnya tidak menyia-nyiakan ruang dengan cara ini. File-file besar dapat terfragmentasi, yaitu dibagi, menjadi beberapa unit alokasi, tetapi setiap unit harus diisi sebelum yang berikutnya dimulai. Defragging mungkin menghemat sedikit ruang dalam tabel alokasi, tetapi ini bukan masalah spesifik Anda.

Solusi yang memungkinkan

Seperti yang disarankan gladiator2345 , satu-satunya pilihan nyata Anda pada titik ini adalah hidup dengannya atau memformat ulang dengan unit alokasi yang lebih kecil.

Kartu Anda mungkin diformat dalam FAT16, yang memiliki batas lebih kecil pada ukuran tabel dan karenanya memerlukan unit alokasi yang jauh lebih besar untuk mengatasi volume yang lebih besar (dengan batas atas 2 GB dengan unit alokasi 32 kB). Sumber milik Braiam . Jika demikian, Anda tetap dapat memformat FAT32 dengan aman.

Ini adalah salah satu situasi di mana mengompresi / pengarsipan ke dalam satu file dapat membantu. Apa yang dikatakan Bob dalam jawabannya adalah benar tetapi solusinya mungkin lebih mudah daripada memformat ulang disk seperti yang disarankan oleh jawaban lain. Jika Anda mengompres atau mengarsipkan direktori (menggunakan zip, tar, atau metode lain) sistem file akan melihat bahwa Anda memiliki satu file besar, bukan beberapa yang lebih kecil. Bahkan tanpa mengompres Anda akan mendapatkan kembali hampir 1,4 GiB ruang kembali, karena semua "file kecil" akan dihitung sebagai satu file besar.

Di dalam ini, aplikasi peta saya menyimpan peta yang di-cache dan aplikasi mendapatkan peta dari Google Maps

Mungkin Anda harus berdiskusi dengan pengembang untuk menggunakan arsip atau database alih-alih beberapa file. Ini mungkin juga akan membantu untuk membuat disk kurang terfragmentasi dan pasti akan menghemat ruang terutama jika itu adalah NAND flash drive. Jika Anda menjelaskan situasi konyol di mana 100MB payload / data berguna menjadi 1.4GiB, ada yang salah dengan bagaimana data disimpan, dan pengembang harus membawa solusi yang lebih bagus.

Jika ada yang dihadapkan dengan masalah ini, mungkin berguna juga untuk mengetahui bahwa alasan lain untuk melihat perbedaan besar dalam ukuran file / ruang pada disk adalah penggunaan stream data alternatif (ADS)

Ini hanya berlaku untuk NTFS untuk pengetahuan saya. ADS dikenal untuk penggunaan yang sah dan tidak sah:

• untuk menandai file yang diunduh dari Internet
• untuk menyimpan metadata (Microsoft ingin memasukkan beberapa fitur Apple OS, seperti tidak menggunakan ekstensi file untuk menentukan jenis file)
• untuk menyembunyikan data atau kode dalam konteks malware .

Secara sederhana ADS: file NTFS apa pun dapat menampung banyak aliran data (pahami "subfil"). Salah satunya adalah aliran utama, digunakan oleh Windows Explorer dan alat-alat Windows lainnya, ia menyimpan konten file yang biasa. Aliran data alternatif dapat berisi informasi lain, persis seperti aliran utama, tetapi mereka tidak dapat ditangani secara langsung oleh alat Windows (khususnya Explorer menampilkan ukuran file sama dengan ukuran aliran utama, terlepas dari ukuran ADS), Anda harus menggunakan alat atau kode khusus untuk menulis, membaca, dan menemukan ADS.

Poin utama adalah bahwa dalam kasus perbedaan ukuran file besar diamati, jangan mengabaikan kemungkinan ADS, dan malware tersembunyi.

Tautan lain .

Untuk bereksperimen dengan ADS dengan aman, coba ini di tingkat DOS / CMD ...

Buat dan tampilkan konten file di root C:

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

Hasil:

C:\> The main data stream

Sekarang tambahkan ADS dengan metode yang sama, cukup tentukan nama ADS di samping nama file:

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

Anda baru saja menyembunyikan pesan rahasia di file. Perhatikan bahwa ukuran file di Explorer tidak berubah meskipun kami menambahkan byte di "rahasia" ADS.

Cobalah untuk menampilkan konten ADS:

C:\> type test.txt:secret

Hasil:

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

CMD typetidak dapat menampilkan konten ADS. Kami akan menggunakan Notepad sebagai gantinya:

notepad test.txt:secret

Di Notepad kita bisa melihat konten ADS:

The secret message

Anda juga dapat menyembunyikan executable penuh dalam ADS dari file teks yang tidak bersalah, dan menjalankannya kapan saja. Kekayaan tidak membahayakan peretas :-)

Masalahnya mungkin karena ukuran cluster.

Menurut Microsoft :

Jika Anda tidak menggunakan kompresi NTFS untuk semua file atau folder yang terdapat pada volume, perbedaan antara SIZE dan SIZE ON DISK adalah ruang yang terbuang karena ukuran cluster yang lebih besar dari yang diperlukan. Anda harus mencoba menggunakan ukuran kluster yang optimal sehingga nilai SIZE ON DISK sedekat mungkin dengan nilai SIZE. Perbedaan yang berlebihan antara SIZE ON DISK dan nilai SIZE adalah indikasi bahwa ukuran kluster default terlalu besar untuk ukuran file rata-rata yang Anda simpan pada volume, dan itu harus dikurangi. Ini dapat dilakukan hanya dengan membuat cadangan volume dan kemudian memformat volume dengan menggunakan perintah format dan / a untuk menentukan ukuran alokasi yang sesuai: IE: format D: /a:2048 (Contoh ini menggunakan ukuran klaster 2-KB).

Cobalah memformat drive Anda dengan ukuran cluster yang lebih kecil.

Saya melihat banyak orang merekomendasikan untuk memformat ulang drive Anda dengan ukuran cluster yang lebih kecil. Karena ini adalah kartu SD, perhatikan bahwa banyak vendor melakukan pra-format kartu ke ukuran kluster yang disarankan agar sesuai dengan ukuran ukuran kluster NAND (menjaga keduanya dalam sinkronisasi sangat penting untuk kinerja baca / tulis yang optimal dan mengurangi keausan)

Anda tidak dapat mengubah ukuran cluster NAND (ini adalah atribut fisik perangkat keras kartu SD Anda).

Pertama jalankan scandisk / chkdsk pada kartu SD Anda untuk memastikan masalah laporan ukuran tidak terletak dalam sistem file yang rusak.

Kedua, saya sarankan Anda melaporkan bug ke Google Map devs, karena merekalah yang harus disalahkan di sini. Mereka harus menggunakan metode penyimpanan yang unggul. Memperbaikinya juga harus membuat aplikasi berjalan lebih cepat di banyak perangkat karena kurang I / O dan aktivitas driver sistem file.

Ini adalah masalah umum dengan banyak sistem file. Ada dua faktor yang bekerja di sini, jumlah maksimum "blok" sistem file dapat menangani per volume logis dan pembatasan fisik media penyimpanan. Hanya 1 file yang dapat dialokasikan ke blok yang diberikan (file umumnya mengambil blok sebanyak yang mereka butuhkan). Jadi file teks dengan 64 byte sering dapat mengambil apa pun dari 4k hingga 32k, tergantung pada ukuran blok dari sistem file tempat ia berada.

Salah satu cara untuk memikirkan hal ini adalah memikirkan setiap blok dalam sistem file sebagai sebuah kotak, dan sistem file sebagai sebuah ruangan. Semua kotak Anda memiliki ukuran yang sama, dan Anda mencoba untuk memuat sebanyak mungkin di sebuah ruangan. Jika Anda memasukkan semuanya dengan lebih banyak ruang yang tersisa, Anda harus mendapatkan kotak yang lebih besar sehingga ruangan itu dipenuhi dengan kotak-kotak.

Salah satu aturan untuk meletakkan barang-barang di dalam kotak adalah bahwa Anda tidak bisa memasukkan dua hal yang tidak terkait dalam sebuah kotak. Mereka harus menjadi bagian dari dokumen yang sama. Jadi jika saya mengetik halaman teks, itu akan memiliki kotak itu sendiri. Jika teks yang saya ketik memiliki begitu banyak halaman sehingga saya tidak bisa memasukkan semuanya dalam satu kotak, saya hanya akan menemukan kotak lain dan terus memasukkan halaman di sana, mengulangi sampai saya memasukkan semua halaman saya. Saya juga telah menuliskan kotak yang saya gunakan untuk dokumen itu dan urutan kotak untuk membacanya secara berurutan.

Bergantung pada bagaimana saya mengatur kotak, saya mungkin hanya memiliki cukup ruang di manifes saya untuk sejumlah kotak. Jadi, jika saya memiliki ruang besar untuk diisi, tetapi hanya sejumlah kecil kotak saya harus menggunakan kotak yang sangat besar untuk mencapai kapasitas ruangan.

Jadi dalam hal itu satu halaman dokumen saya masih akan menempati satu kotak, tanpa ada yang membagikannya.

Situasi yang sama terjadi di antara berbagai solusi penyimpanan. FAT32 hanya dapat mengelola apa yang dianggap sebagai jumlah "kotak" yang rendah pada hard drive besar saat ini, sehingga berakhir dengan "kotak" yang sangat besar untuk mengimbangi ini.

Selain ukuran cluster, Anda juga dapat memiliki perbedaan karena kondisi berikut:

• File yang dikompresi atau dienkripsi dapat menggunakan ruang yang berbeda dari ukuran file yang logis.
• File tertaut akan melaporkan n kali jumlah tautan kali ukuran file untuk ukuran file logis, tetapi ruang fisik yang digunakan biasanya lebih sedikit.

Anda harus melihat entri Suballokasi Blok di Wikipedia. Itulah tepatnya yang terjadi pada Anda. Menggunakan sistem file dengan dukungan untuk Tail Tail adalah solusi level sistem file untuk masalah ini selain mengubah ukuran cluster alokasi.

Semua memiliki ketidaknyamanan karena perlu memformat ulang disk.

Dalam beberapa kasus, hanya menyimpan file-file itu dalam arsip akan memperbaiki masalah (dan file-file kecil juga akan dikompresi di samping menghentikan kehilangan ruang di akhir file). Ini tidak nyaman menghabiskan waktu untuk dekompresi.

Pilihan lain jika Anda memiliki begitu banyak file kecil karena beberapa masalah terkait aplikasi spesifik adalah menyimpan data perangkat lunak Anda menggunakan metode lain (mungkin dalam database). Tapi tentu saja itu solusi untuk programmer, bukan pengguna akhir.

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

Saya mencatat perbedaan ukuran file besar di Windows 10 pada file individual, tetapi jika saya melihat properti file SAMA dari lokasi yang sama (drive jaringan), dengan Windows XP, perbedaan besar tidak ada; hanya perbedaan kecil, itulah yang Anda harapkan. Saya pikir ada bug di Windows 10. File yang 449MB mungkin tidak memakan 3,99GB, itulah yang dikatakan Windows 10 kepada saya.