Sering kali, nilai untuk 'Size' dan 'Size on disk' akan sangat mendekati kecocokan saat memeriksa ukuran folder atau file, tetapi bagaimana jika ada perbedaan besar di antara keduanya? Pos T&J SuperUser hari ini membahas jawaban untuk masalah yang membingungkan ini.
Sesi Tanya & Jawab hari ini hadir atas kebaikan SuperUser — subdivisi Stack Exchange, pengelompokan situs web Tanya Jawab berbasis komunitas.
Pertanyaan
Pembaca SuperUser thelastblack ingin tahu mengapa ada perbedaan besar antara 'Size' dan 'Size on disk' untuk folder di kartu SD ponselnya:
Seperti yang Anda lihat di bawah, ada banyak perbedaan antara kolom 'Size' dan 'Size on disk' untuk folder ini. Mengapa demikian?
Saya tahu bahwa 'Ukuran di disk' harus lebih banyak daripada 'Ukuran' karena unit alokasi di Windows, tetapi mengapa ada banyak perbedaan? Mungkinkah karena jumlah file yang banyak?
BTW, folder ini ada di kartu SD ponsel Android saya. Di dalamnya, aplikasi peta saya menyimpan peta yang disimpan dalam cache, dan aplikasi tersebut mendapatkan petanya dari Google Maps.
Melihat tangkapan layar, pasti ada perbedaan besar antara 'Ukuran' dan 'Ukuran di disk', jadi apa yang terjadi di sini yang menyebabkan hal ini?
Jawabannya
Kontributor SuperUser Bob memiliki jawabannya untuk kami:
Saya akan berasumsi bahwa Anda menggunakan sistem file FAT / FAT32 di sini, karena Anda menyebutkan ini adalah kartu SD. NTFS dan exFAT berperilaku serupa sehubungan dengan unit alokasi. Sistem file lain mungkin berbeda, tetapi sistem tersebut tidak didukung di Windows.
Jika Anda memiliki banyak file kecil, hal ini sangat memungkinkan. Pertimbangkan ini:
- 50.000 file
- Ukuran cluster 32 KB (unit alokasi), yang merupakan maksimum untuk FAT32
Oke, sekarang minimum spasi yang diambil adalah 50.000 * 32.000 = 1,6 GB (menggunakan awalan SI, bukan biner, untuk menyederhanakan matematika). Ruang yang dibutuhkan 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 berukuran rata-rata 2 KB, Anda akan mendapatkan total sekitar 100 MB - tetapi Anda juga membuang rata-rata 15x itu (30 KB per file) karena ukuran unit alokasi.
Penjelasan Mendalam
Mengapa ini terjadi? Nah, sistem file FAT32 perlu melacak di mana setiap file disimpan. Jika itu menyimpan daftar setiap byte, tabel (seperti buku alamat) akan tumbuh dengan kecepatan yang sama dengan datanya - dan membuang banyak ruang. Jadi yang mereka lakukan adalah menggunakan "unit alokasi", yang juga dikenal sebagai "ukuran cluster". Volume dibagi menjadi unit alokasi ini, dan sejauh menyangkut sistem file, mereka tidak dapat dibagi lagi - itu adalah blok terkecil yang dapat diatasi. Sama seperti Anda memiliki nomor rumah, tetapi tukang pos Anda tidak peduli berapa banyak kamar tidur yang Anda miliki atau siapa yang tinggal di dalamnya.
Jadi apa yang terjadi jika Anda memiliki file yang sangat kecil? Sistem file tidak peduli jika file berukuran 0 KB, 2 KB, atau bahkan 15 KB, itu akan memberikan ruang paling sedikit - dalam contoh di atas, itu 32 KB. File Anda hanya menggunakan sedikit ruang ini, dan sisanya pada dasarnya terbuang percuma, tetapi masih menjadi milik file - seperti kamar tidur yang Anda tinggalkan kosong.
Mengapa ada ukuran unit alokasi yang berbeda? Nah, ini menjadi trade-off 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 akan mendapatkan unit baru (rumah) sampai yang lainnya terisi. Jika Anda memiliki banyak file kecil, nah, Anda akan memiliki meja besar (buku alamat), jadi sebaiknya beri mereka unit kecil (rumah).
Unit alokasi yang besar, sebagai aturan umum, akan membuang banyak ruang jika Anda memiliki banyak file kecil. Biasanya tidak ada alasan yang baik untuk menggunakan di atas 4 KB untuk penggunaan umum.
Fragmentasi?
Sedangkan untuk fragmentasi, fragmentasi tidak boleh menyia-nyiakan ruang dengan cara ini. File besar dapat terfragmentasi, misalnya dipecah, menjadi beberapa unit alokasi, tetapi setiap unit harus diisi sebelum unit berikutnya dimulai. Mendefragmentasi mungkin menghemat sedikit ruang di tabel alokasi, tetapi ini bukan masalah khusus Anda.
Solusi yang memungkinkan
Sebagai gladiator2345 disarankan , satu-satunya pilihan nyata Anda saat ini adalah menerimanya 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 menangani volume yang lebih besar (dengan batas atas 2 GB dengan unit alokasi 32 KB). Sumber courtesy of Braiam . Jika demikian, Anda harus dapat memformat dengan aman sebagai FAT32.
Punya sesuatu untuk ditambahkan ke penjelasannya? Suarakan di komentar. Ingin membaca lebih banyak jawaban dari pengguna Stack Exchange yang paham teknologi? Lihat utas diskusi lengkap di sini .
