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

302

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

Cuplikan layar memperlihatkan 50.875 file dalam 1.504 folder, 105 MB menjadi 1,43 GB pada disk

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.

vfsoraki
sumber
10
Halo blastblack, dan selamat datang di SuperUser. Saya mengedit pertanyaan Anda untuk menghapus bagian tentang defragmenting, karena dua jawaban yang ada fokus pada ukuran / ukuran pada diskrepancy dan format Stack Exchange bekerja paling baik ketika setiap pertanyaan yang diposting adalah tentang satu hal. Namun Anda tentu dapat mengajukan kembali pertanyaan itu sebagai pertanyaan terpisah, meskipun saya pikir jawaban yang Anda terima sejauh ini pada pertanyaan ini menunjukkan bahwa defragmentasi tidak akan membantu Anda. (Biasanya juga tidak ada gunanya di media solid-state.) Jangan ragu untuk mengedit pertanyaan Anda lebih lanjut jika Anda merasa saya mengubah niat Anda dengan cara apa pun.
CVn
1
@ MichaelKjörling Heh, saya baru saja mengedit dalam diskusi kecil tentang fragmentasi (sedikit teralihkan sebelumnya)
Bob
21
@ MichaelKjörling Jangan mengedit pertanyaan secara surut agar sesuai dengan jawaban. Salah satu jawaban membahas bagian fragmentasi dari pertanyaan OP. Hasil edit Anda harus diputar kembali untuk menghindari kebingungan.
DanteTheEgregore
5
@DanteTheEgregore Jika Anda merujuk pada jawaban Bob, yang memang telah diedit juga membahas efek fragmentasi, maka sebelum melompati pistol, silakan periksa riwayat edit dan cap waktu pada jawaban dan pertanyaan itu. Pada saat edit saya, jawaban Bob tidak mencakup masalah fragmentasi sama sekali. Jika OP ingin melakukannya, mengedit kembali "akan defragmenting media membantu saya dengan ini?" harus menyelesaikan setiap kebingungan yang luar biasa, meskipun saya masih merasa itu lebih baik ditanyakan sebagai pertanyaan terpisah; IMO masalah perbedaan antara dua nilai tidak berhubungan.
CVn
11
Menurut saya aplikasi ini diprogram dengan sangat buruk - pertimbangkan untuk melaporkan bug. Saya bukan seorang programmer profesional, tetapi saya pernah meretas sesuatu yang serupa di JavaME, dan tentu saja salah satu masalah yang harus saya selesaikan adalah bagaimana cara menyimpan semua ubin peta kecil secara efisien (penyimpanan & akses) dalam sebuah wadah. Saya akhirnya menggunakan file zip tidak terkompresi.
A. Donda

Jawaban:

303

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.

Bob
sumber
3
Ruang terbuang karena ukuran alokasi minimum sebenarnya secara teknis disebut "fragmentasi internal", sehingga Anda dapat mengatakan bahwa fragmentasi adalah biang keladinya. Tapi itu masih bukan sesuatu yang bisa dilakukan alat "defragment" apa pun.
hobbs
3
(Kurang teknis, ini hanya disebut "kendur".)
hobbs
1
Ukuran cluster juga membatasi ukuran filesystem maksimum. Misalnya, jika ruang alamat Anda 32-bit, Anda memiliki total ~ 4,29 miliar total cluster yang mungkin. Sekarang, jika Anda menggunakan ukuran klaster terkecil yang didukung oleh NTFS (512 byte), Anda dapat mengatasi maksimal 512 * 2 ^ 32 byte = 2 GiB. Jika Anda membutuhkan volume yang dapat menyimpan lebih dari 2 GiB data, Anda harus menambah ukuran cluster. Ini semua terlepas dari file terbesar sebenarnya yang Anda coba simpan, asalkan Anda tidak dapat menyimpan file yang lebih besar dari 2 GiB yang merupakan masalah Anda yang paling kecil.
Andon M. Coleman
4 KiB cluster akan memungkinkan Anda untuk menangani file dalam volume hingga 16 TiB, yang harus cukup untuk masa mendatang.
Andon M. Coleman
1
Yah, dia bisa mengompres arsip file kecilnya menjadi satu file besar.
einpoklum
45

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.

Braiam
sumber
1
> 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 satu) akan memerlukan dukungan dari aplikasi pemetaan ini.
Bob
1
@ Bob maka solusinya harus berasal dari sisi pengembang D:
Braiam
4
Itu sepenuhnya benar. Saya pikir untuk saat ini, saya harus mengubah aplikasi saya.
vfsoraki
17
@Braiam Ini tidak menipu sistem file untuk berpikir hanya ada satu file; ada adalah hanya satu file. Mengapa pengembang tidak menyimpan informasi cache dalam arsip, itu mungkin karena sebagian besar format arsip tidak dirancang untuk penulisan acak cepat, yang tentu saja dibutuhkan oleh cache. Alternatif yang lebih baik mungkin menggunakan pustaka basis data ringan seperti SQLite.
bcrist
1
Benar sekali ..... +1
arundevma
25

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 :-)

mnt
sumber
Saya bukan orang yang menang, pekerjaan saya kebanyakan dilakukan di Linux. Ini sangat berguna. Terima kasih
vfsoraki
4
Ada baiknya menggunakan alat seperti Streams dari Sysinternals untuk memeriksa penggunaan ADS. Misalnya file yang diunduh pada sistem Windows dapat ditandai dengan sumber dalam ADS, meskipun ini kecil dan tidak memakan tempat. Ini tidak akan ditampilkan dalam dir atau keluaran Explorer biasanya. Ini mungkin mengambil blok dan memperparah masalah penggunaan disk yang Anda selidiki. .
adric
19

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.

arundevma
sumber
4
Yang telah dikatakan, seseorang seharusnya tidak membuat ukuran cluster kurang dari 4096 byte atau tidak hanya kelipatan dari angka ini. OS 32 bit bekerja dengan halaman yang (dalam kasus non-PAE) adalah 4096 byte, jadi menggunakan cluster non-banyak dapat secara negatif mempengaruhi kinerja sistem file. Inilah sebabnya mengapa ukuran standar diatur ke 4096 byte.
Ruslan
2
Untuk menambahkan apa yang dikatakan @Ruslan, hard drive yang lebih baru sekarang memiliki ukuran sektor 4 kB, dan akan lebih optimal untuk menyelaraskan sistem file ke sektor fisik, dan memiliki kelipatan dari ukuran sektor fisik sebagai ukuran unit alokasi.
Bob
1
@Ruslan Saya percaya Anda bermaksud mengatakan bahwa itu harus menjadi kekuatan dua kali 4096. 12288 (3 × 4096) dan 20480 (5 × 4096) bukan pilihan bagus.
Scott
9

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.

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

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.

CyberSkull
sumber
6

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.
Archimedes Trajano
sumber
Secara umum, itu bisa benar. Tetapi dalam kasus saya, unit alokasi tinggi adalah masalahnya.
vfsoraki
3
Yup, saya hanya mencoba menambahkan jawaban dengan memberikan lebih banyak alasan yang mungkin untuk perbedaan tersebut.
Archimedes Trajano
6

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

Kriss
sumber
0

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.

David Hutchins
sumber
1
Hanya FYI, pertanyaannya tidak ada hubungannya dengan Windows 10. OP menggunakan windows 7.
TheKB