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


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

Screenshot showing 50,875 files in 1,504 folders, 105 MB being 1.43 GB on disk

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

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


295
2018-01-20 09:48


asal


Halo thelastblack, dan selamat datang di SuperUser. Saya mengedit pertanyaan Anda untuk menghapus bagian tentang defragmenting, karena dua jawaban yang ada berfokus pada ukuran / ukuran pada diskrepansi disk dan format Stack Exchange berfungsi paling baik ketika setiap pertanyaan yang diposting adalah tentang satu hal. Anda tentu saja dapat bertanya ulang sebagai pertanyaan terpisah, meskipun saya pikir jawaban yang Anda terima sejauh ini pada pertanyaan ini menunjukkan bahwa defragmentasi tidak akan membantu Anda. (Ini juga umumnya tidak baik pada media solid-state.) Jangan ragu untuk sunting pertanyaan Anda lebih lanjut jika Anda merasa saya mengubah maksud Anda dengan cara apa pun. - Michael Kjörling
@ MichaelKjörling Heh, saya baru saja mengedit dalam diskusi kecil tentang fragmentasi (sedikit teralihkan sebelumnya) - Bob
@ MichaelKjörling Jangan edit pertanyaan secara retroaktif agar sesuai dengan jawaban. Salah satu jawaban membahas bagian fragmentasi pertanyaan OP. Hasil edit Anda perlu digulirkan kembali untuk menghindari kebingungan. - DanteTheEgregore
@DanteTheEgregore Jika Anda mengacu pada jawaban Bob, yang memang telah diedit untuk juga membahas efek fragmentasi, maka sebelum melompat pistol, silakan periksa riwayat pengeditan dan cap waktu pada jawaban itu dan pertanyaannya. Pada saat suntingan saya, jawaban Bob tidak mencakup masalah fragmentasi sama sekali. Jika OP ingin melakukannya, mengedit kembali "akankah defragmenting media membantu saya dengan ini?" harus menyelesaikan kebingungan yang luar biasa, meskipun saya masih merasa yang lebih baik ditanyakan sebagai pertanyaan terpisah; IMO soal perbedaan antara dua nilai tidak berhubungan. - Michael Kjörling
Bagi saya sepertinya aplikasi ini benar-benar diprogram dengan buruk - pertimbangkan untuk mengajukan laporan bug. Saya bukan pemrogram profesional, tetapi saya pernah meretas sesuatu yang serupa di JavaME, dan tentu saja salah satu masalah yang harus saya pecahkan adalah bagaimana menyimpan semua petak peta kecil itu secara efisien (penyimpanan & akses) dalam sebuah wadah. Saya akhirnya menggunakan file zip yang tidak terkompresi. - A. Donda


Jawaban:


Saya akan mengasumsikan bahwa Anda menggunakan filesystem FAT / FAT32 di sini, karena Anda menyebutkan ini adalah kartu SD. NTFS dan exFAT berperilaku serupa terkait dengan unit alokasi. Filesystem lain mungkin berbeda, tetapi mereka tidak didukung pada Windows.

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

  • 50.000 file.

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

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

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


Penjelasan yang mendalam

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

Jadi apa yang terjadi jika Anda memiliki file yang sangat kecil? Nah, filesystem tidak peduli jika file tersebut adalah 0 kB, 2 kB atau bahkan 15 kB, itu akan memberikan ruang yang paling sedikit - pada contoh di atas, yaitu 32 kB. File Anda hanya menggunakan sejumlah kecil ruang ini, dan sisanya pada dasarnya terbuang 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 terbuang 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, yah, Anda akan memiliki meja besar (buku alamat), jadi semoga juga memberi mereka unit kecil (rumah).

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


Fragmentasi?

Adapun fragmentasi, fragmentasi tidak membuang-buang ruang dengan cara ini. File besar dapat dibagi-bagi, yaitu dibagi menjadi beberapa unit alokasi, tetapi setiap unit harus diisi sebelum yang berikutnya dimulai. Defragging mungkin menghemat sedikit ruang di tabel alokasi, tetapi ini bukan masalah khusus Anda.


Solusi yang memungkinkan

Sebagai gladiator2345 disarankan, satu-satunya opsi nyata Anda pada saat ini adalah untuk 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 oleh karena itu memerlukan unit alokasi yang jauh lebih besar untuk mengatasi volume yang lebih besar (dengan batas atas 2 GB dengan unit alokasi 32 kB). Sumber courtesy of Braiam. Jika itu kasusnya, Anda harus dapat dengan aman memformat sebagai FAT32 pula.


299
2018-01-20 09:54



Ruang yang terbuang karena ukuran alokasi minimum sebenarnya secara teknis disebut "fragmentasi internal", jadi Anda bisa mengatakan bahwa fragmentasi adalah pelakunya. Tapi itu masih bukan sesuatu yang alat "defragment" dapat melakukan apa saja. - hobbs
(Kurang teknis, itu hanya disebut "slack".) - hobbs
Ukuran cluster juga membatasi ukuran filesystem maksimum. Misalnya, jika ruang alamat Anda 32-bit, Anda memiliki total ~ 4,29 miliar kemungkinan total kluster. Sekarang, jika Anda menggunakan ukuran cluster terkecil yang didukung oleh NTFS (512 bytes), Anda dapat mengatasi maksimum 512 * 2 ^ 32 byte = 2 GiB. Jika Anda membutuhkan volume yang dapat menyimpan lebih dari 2 GiB data, Anda harus meningkatkan ukuran klaster. Ini semua terlepas dari file terbesar yang Anda coba simpan, Anda tidak dapat menyimpan file yang lebih besar dari 2 GiB yang merupakan masalah Anda yang paling sedikit. - Andon M. Coleman
4 KiB cluster akan memungkinkan Anda untuk menangani file dalam volume yang hingga 16 TiB dalam ukuran, yang seharusnya cukup untuk masa mendatang. - Andon M. Coleman
Yah, dia bisa memampatkan arsipnya dari file-file kecil menjadi satu file besar. - einpoklum


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

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

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


46
2018-01-20 15:03



> Di dalam ini, aplikasi peta saya menyimpan peta yang di-cache dan aplikasi mendapatkan peta dari Google Maps. - sayangnya, dalam hal ini, kompresi (yang secara efektif merupakan sistem file di atas basis) akan memerlukan dukungan dari aplikasi pemetaan ini. - Bob
@Bob, maka solusinya harus berasal dari sisi pengembang D: - Braiam
Itu sepenuhnya benar. Saya pikir untuk saat ini, saya harus mengubah aplikasi saya. - vfsoraki
@Braiam Ini bukan menipu sistem file agar berpikir hanya ada satu file; sana aku s hanya satu file. Seperti mengapa pengembang tidak menyimpan informasi cache dalam arsip, itu mungkin karena sebagian besar format arsip tidak dirancang untuk penulisan acak cepat, yang tentu saja memerlukan cache. Alternatif yang lebih baik mungkin menggunakan pustaka basis data yang ringan seperti SQLite. - bcrist
Benar sekali ..... +1 - arundevma


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

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

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

Hanya ADS: setiap file NTFS dapat menyimpan beberapa aliran data (mengerti "subfiles"). Salah satunya adalah aliran utama, yang digunakan oleh Windows Explorer dan alat Windows lainnya, ia menyimpan konten biasa dari sebuah file. Aliran data alternatif dapat berisi informasi lain, persis sebagai aliran utama, tetapi tidak dapat ditangani langsung oleh alat Windows (terutama Explorer menampilkan ukuran file sama dengan ukuran aliran utama, terlepas dari ukuran ADS), Anda harus menggunakan alat atau kode khusus untuk menulis, membaca, dan mencari ADS.

Poin utamanya adalah bahwa dalam hal perbedaan ukuran file besar yang diamati, jangan mengabaikan kemungkinan ADS, dan malware yang tersembunyi.

Tautan lain.

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

Buat dan kemudian 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 sebagai tambahan nama file:

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

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

Coba untuk menampilkan konten ADS:

C:\> type test.txt:secret

Hasil:

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

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

notepad test.txt:secret

Di Notepad kita dapat melihat isi dari ADS:

The secret message

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


25
2018-01-21 07:37



Saya bukan win-man sendiri, pekerjaan saya kebanyakan dilakukan di Linux. Ini sangat berguna. Terima kasih - vfsoraki
Ini layak menggunakan alat seperti Streaming dari Sysinternals untuk memeriksa penggunaan ADS. Misalnya file yang diunduh pada sistem Windows dapat diberi tag dengan sumber di ADS, meskipun ini kecil dan tidak membutuhkan ruang. Itu tidak akan ditampilkan dalam dir atau Explorer output biasanya. Ini mungkin memakan blok dan memperburuk masalah penggunaan disk yang Anda selidiki. . - adric


Masalahnya mungkin karena ukuran cluster.

Menurut Microsoft:

Jika Anda tidak menggunakan kompresi NTFS untuk file atau folder apa pun   terkandung pada volume, perbedaan antara SIZE dan SIZE ON DISK   adalah ruang yang terbuang karena ukuran cluster yang lebih besar dari yang diperlukan. Kamu   harus mencoba menggunakan ukuran kluster optimal sehingga SIZE ON DISK   nilainya sedekat mungkin dengan nilai SIZE. Terlalu banyak   perbedaan antara SIZE ON DISK dan nilai SIZE adalah sebuah   indikasi bahwa ukuran kluster default terlalu besar untuk rata-rata   ukuran file yang Anda simpan pada volume, dan seharusnya   menurun. Ini dapat dilakukan hanya dengan membackup volume dan kemudian   format ulang volume dengan menggunakan perintah format dan tombol / a   untuk menentukan ukuran alokasi yang sesuai: IE: format D: /a:2048   (Contoh ini menggunakan ukuran kluster 2-KB).

Coba format drive Anda dengan ukuran cluster yang lebih kecil.


19
2018-01-20 09:57



Yang telah dikatakan, orang seharusnya tidak membuat ukuran cluster kurang dari 4096 byte atau hanya tidak kelipatan dari angka ini. OS 32 bit bekerja dengan halaman yang (dalam non-PAE case) adalah 4096 byte, jadi menggunakan non-multiple cluster dapat berdampak negatif terhadap kinerja sistem file. Inilah sebabnya ukuran default ditetapkan menjadi 4096 byte. - Ruslan
Untuk menambahkan pada apa yang dikatakan @Ruslan, hard drive yang lebih baru sekarang memiliki ukuran sektor 4 kB, dan akan optimal untuk menyelaraskan sistem file ke sektor fisik, dan memiliki kelipatan dari ukuran sektor fisik sebagai ukuran unit alokasi. - Bob
@Ruslan Saya percaya Anda bermaksud mengatakan bahwa itu harus menjadi kekuatan dua kali 4096. 12288 (3 × 4096) dan 20480 (5 × 4096) bukanlah pilihan yang bagus. - Scott


Saya melihat banyak orang menyarankan 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 klaster yang disarankan agar sesuai dengan ukuran ukuran gugus NAND (menjaga keduanya tetap sinkron adalah sangat penting untuk kinerja baca / tulis 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 ukuran laporan tidak berada di dalam filesystem yang rusak.

Kedua, saya sarankan Anda melaporkan bug tersebut ke Google Map devs, karena mereka yang harus disalahkan di sini. Mereka harus menggunakan metode penyimpanan superior. Memperbaiki itu juga harus membuat aplikasi untuk berjalan lebih cepat pada banyak perangkat karena lebih sedikit I / O dan aktivitas driver sistem file.


9
2018-01-21 18:20



Sebenarnya, itu bukan Google Maps, tetapi aplikasi lain menggunakan peta Google. Saya memberi tahu pengembang, dan baru saja menghapus file-file itu dari SD saya. - vfsoraki


Ini adalah masalah umum dengan banyak filesystem. Ada dua faktor yang berfungsi di sini, jumlah maksimum "pemblokiran" yang dapat ditangani oleh filesystem per volume logis dan pembatasan fisik dari media penyimpanan. Hanya 1 file yang dapat dialokasikan ke blok tertentu (file biasanya mengambil sebanyak mungkin blok yang mereka butuhkan). Jadi file teks dengan 64 byte sering dapat mengambil apa pun dari 4k hingga 32k, tergantung pada ukuran blok dari sistem berkas yang ada.

Salah satu cara untuk berpikir tentang ini adalah memikirkan setiap blok di filesystem sebagai kotak, dan filesystem sebagai sebuah ruangan. Semua kotak Anda berukuran sama, dan Anda mencoba mencocokkan sebanyak yang Anda bisa di sebuah ruangan. Jika Anda memenuhi semuanya dengan lebih banyak ruang tersisa, Anda harus mendapatkan kotak yang lebih besar sehingga ruangan itu dipenuhi dengan kotak-kotak.

Salah satu aturan untuk meletakkan sesuatu di kotak adalah bahwa Anda tidak dapat meletakkan dua hal yang tidak terkait dalam kotak. Mereka harus menjadi bagian dari dokumen yang sama. Jadi jika saya mengetikkan halaman teks, itu akan memiliki kotak itu sendiri. Jika teks yang saya ketik memiliki begitu banyak halaman, saya tidak bisa memasukkan semuanya ke dalam satu kotak, saya hanya akan mencari kotak lain dan terus meletakkan 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 cara saya mengatur kotak-kotak itu, saya mungkin hanya memiliki cukup ruang dalam manifes saya untuk sejumlah kotak tertentu. 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 ini dokumen satu halaman 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" rendah pada hard drive besar saat ini, sehingga berakhir dengan "kotak" yang sangat besar untuk mengimbangi ini.


7
2018-01-20 14:50





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

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

6
2018-01-20 17:42



Secara umum, itu mungkin benar. Tetapi dalam kasus saya, unit alokasi tinggi adalah masalahnya. - vfsoraki
Yup saya hanya mencoba menambah jawaban dengan memberikan alasan yang lebih mungkin untuk perbedaan tersebut. - Archimedes Trajano


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

Semua memiliki ketidaknyamanan perlu memformat ulang disk.

Dalam beberapa kasus hanya menyimpan file-file dalam arsip akan memperbaiki masalah (dan file-file kecil juga akan dikompresi di samping berhenti kehilangan ruang di akhir file). Ini memiliki ketidaknyamanan menghabiskan beberapa waktu untuk dekompresi.

Pilihan lain jika Anda memiliki begitu banyak file kecil karena beberapa masalah terkait aplikasi tertentu 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


6
2018-01-20 15:00





Saya mencatat perbedaan ukuran file besar di Windows 10 pada file individu, 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. Sebuah file yang 449MB mungkin tidak memakan 3,99GB, yang adalah apa yang dikatakan Windows 10 kepada saya.


0
2018-06-15 17:57



Hanya FYI, pertanyaannya tidak ada hubungannya dengan Windows 10. OP menggunakan windows 7. - TheKB