Dalam pers teknologi informal (yaitu jurnalistik), dan di blog teknologi online dan forum diskusi, orang biasanya menemukan saran anekdotal untuk membiarkan sejumlah ruang kosong di hard disk drive atau solid state drive. Berbagai alasan diberikan, atau terkadang tanpa alasan sama sekali. Dengan demikian, klaim-klaim ini, walaupun mungkin masuk akal dalam praktiknya, memiliki kesan mistis tentangnya. Misalnya:

• Setelah disk Anda 80% penuh, Anda harus menganggapnya penuh , dan Anda harus segera menghapus atau memutakhirkan. Jika mereka mencapai 90% penuh, Anda harus mempertimbangkan celana pribadi Anda terbakar, dan bereaksi dengan kecepatan kedekatan yang tepat untuk memperbaikinya. ( Sumber .)

• Untuk menjaga pengumpulan sampah tetap pada efisiensi puncak, saran tradisional bertujuan untuk menjaga 20 hingga 30 persen dari drive Anda kosong. ( Sumber .)

• Saya telah diberitahu bahwa saya harus meninggalkan sekitar 20% gratis pada HD untuk kinerja yang lebih baik, bahwa HD benar-benar melambat ketika hampir penuh. ( Sumber .)

• Anda harus meninggalkan ruang untuk file swap dan file sementara. Saat ini saya membiarkan 33% persen gratis dan dan bersumpah untuk tidak mendapatkan di bawah 10GB ruang HDD gratis. ( Sumber .)

• Saya akan mengatakan biasanya 15%, namun dengan seberapa besar hard drive sekarang aday, selama Anda memiliki cukup untuk file temp dan swap file Anda, secara teknis Anda aman. ( Sumber .)

• Saya akan merekomendasikan 10% plus pada Windows karena defrag tidak akan berjalan jika tidak ada banyak gratis di drive ketika Anda menjalankannya. ( Sumber .)

• Anda umumnya ingin membiarkan sekitar 10% gratis untuk menghindari fragmentasi ( Sumber .)

• Jika drive Anda secara konsisten lebih dari 75 atau 80 persen penuh, upgrade ke SSD yang lebih besar patut dipertimbangkan. ( Sumber .)

Apakah ada penelitian, lebih disukai yang diterbitkan dalam jurnal peer-review, baik dalam persentase atau jumlah absolut ruang bebas yang diperlukan oleh kombinasi spesifik dari sistem operasi, sistem file, dan teknologi penyimpanan (misalnya piring magnet vs keadaan padat)? (Idealnya, penelitian semacam itu juga akan menjelaskan alasan untuk tidak melebihi jumlah ruang yang digunakan, misalnya untuk mencegah sistem kehabisan ruang swap , atau untuk menghindari kehilangan kinerja.)

Jika Anda mengetahui riset semacam itu, saya akan berterima kasih jika Anda dapat menjawabnya dengan tautan ke sana plus ringkasan singkat dari temuan-temuan tersebut. Terima kasih!

Apakah ada penelitian, lebih disukai diterbitkan dalam jurnal peer-review [...]?

Kita harus kembali lebih jauh dari 20 tahun, administrasi sistem atau lainnya, untuk ini. Ini adalah topik hangat, setidaknya di dunia komputer pribadi dan sistem operasi workstation, lebih dari 30 tahun yang lalu; waktu ketika orang-orang BSD sedang mengembangkan Sistem File Cepat Berkeley dan Microsoft dan IBM sedang mengembangkan Sistem File Kinerja Tinggi.

Literatur tentang kedua oleh penciptanya membahas cara-cara bagaimana sistem file ini diorganisir sehingga kebijakan alokasi blok menghasilkan kinerja yang lebih baik dengan mencoba membuat blok file yang berurutan berdekatan. Anda dapat menemukan diskusi tentang ini, dan fakta bahwa jumlah dan lokasi ruang kosong yang tersisa untuk mengalokasikan blok mempengaruhi penempatan blok dan dengan demikian kinerja, dalam artikel kontemporer tentang subjek.

Seharusnya cukup jelas, misalnya, dari deskripsi algoritma alokasi blok dari Berkeley FFS bahwa jika tidak ada ruang kosong dalam grup silinder saat ini dan sekunder dan algoritme dengan demikian mencapai fallback tingkat keempat ("terapkan pencarian lengkap untuk semua grup silinder ") kinerja pengalokasian blok disk akan menderita seperti juga fragmentasi file (dan karenanya membaca kinerja).

Ini adalah ini dan analisis serupa (ini jauh dari satu-satunya desain sistem file yang bertujuan untuk memperbaiki kebijakan tata letak desain sistem file saat itu) yang telah diterima oleh kebijaksanaan selama 30 tahun terakhir.

Sebagai contoh: Diktum dalam makalah asli bahwa volume FFS disimpan kurang dari 90% penuh, jangan sampai kinerja buruk, yang didasarkan pada eksperimen yang dibuat oleh pencipta, dapat ditemukan berulang tanpa kritis bahkan dalam buku-buku tentang sistem file Unix yang diterbitkan abad ini ^{(misalnya Pate2003 hal. 216)} . Hanya sedikit orang yang mempertanyakan hal ini, meskipun Amir H. Majidimehr benar-benar melakukannya seabad sebelumnya, mengatakan bahwa xe dalam praktiknya tidak mengamati efek yang nyata; paling tidak karena mekanisme Unix adat yang cadangan yang akhir 10% untuk digunakan superuser, yang berarti bahwa disk penuh 90% efektif 100% penuh untuk non-superusers pula ^{(Majidimehr1996 p. 68)}. Begitu pula Bill Calkins, yang menyarankan bahwa dalam praktiknya orang dapat mengisi hingga 99%, dengan ukuran disk abad ke-21, sebelum mengamati efek kinerja ruang bebas yang rendah karena bahkan 1% dari cakram ukuran modern sudah cukup untuk memiliki banyak ruang bebas yang tidak difragmentasi. masih bermain dengan ^{(Calkins2002 hal. 450)} .

Yang terakhir ini adalah contoh bagaimana kebijaksanaan yang diterima dapat menjadi salah. Ada contoh lain dari ini. Sama seperti dunia SCSI dan ATA dunia pengalamatan blok logis dan perekaman bit yang dikategorikan agak membuang dari jendela semua perhitungan latensi rotasi yang hati-hati dalam desain sistem file BSD, sehingga mekanisme fisik SSD agak membuang jendela ruang kosong menerima kebijaksanaan yang berlaku untuk cakram Winchester.

Dengan SSD, jumlah ruang kosong pada perangkat secara keseluruhan , yaitu di semua volume pada disk dan di antara mereka , memiliki efek baik pada kinerja dan seumur hidup. Dan dasar untuk gagasan bahwa file perlu disimpan dalam blok dengan alamat blok logis yang berdekatan dilemahkan oleh fakta bahwa SSD tidak memiliki piring untuk memutar dan kepala untuk mencari. Aturan berubah lagi.

Dengan SSD, jumlah ruang bebas minimum yang disarankan sebenarnya lebih dari 10% tradisional yang berasal dari percobaan dengan cakram Winchester dan Berkeley FFS 33 tahun yang lalu. Anand Lal Shimpi memberi 25%, misalnya. Perbedaan ini diperparah oleh kenyataan bahwa ini harus menjadi ruang bebas di seluruh perangkat , sedangkan angka 10% berada dalam setiap volume FFS tunggal , dan dengan demikian dipengaruhi oleh apakah program pemartisian seseorang tahu untuk TRIM semua ruang yang tidak dialokasikan ke volume disk yang valid oleh tabel partisi.

Hal ini juga diperparah oleh kompleksitas seperti driver filesystem yang menyadari TRIM yang dapat TRIM mengosongkan ruang dalam volume disk, dan fakta bahwa produsen SSD sendiri juga telah mengalokasikan berbagai tingkat ruang yang disediakan yang bahkan tidak terlihat melebihi perangkat (yaitu untuk host) ) untuk berbagai kegunaan seperti pengumpulan sampah dan perataan keausan.

Bibliografi

• Marshall K. McKusick, William N. Joy, Samuel J. Leffler, dan Robert S. Fabry (1984-08). Sistem File Cepat untuk UNIX . Transaksi ACM pada Sistem Komputer. Volume 2 edisi 3. hlm.181–197. Diarsipkan di cornell.edu.
• Roy Duncan (1989-09). Desain tujuan dan implementasi Sistem File Kinerja Tinggi yang baru . Jurnal Sistem Microsoft . Volume 4 edisi 5. hlm. 1–13. Diarsipkan di wisc.edu.
• Marshall Kirk McKusick, Keith Bostic, Michael J. Karels, dan John S. Quarterman (1996-04-30). "Sistem File Cepat Berkeley". Desain dan Implementasi Sistem Operasi 4.4 BSD . Addison-Wesley Professional. ISBN 0201549794.
• Dan Bridges (1996-05). Di dalam Sistem File Kinerja Tinggi - Bagian 4: Fragmentasi, Bitmap Diskspace, dan Halaman Kode . Bit yang signifikan. Diarsipkan di Majalah Pengembang Elektronik untuk OS / 2.
• Keith A. Smith dan Margo Seltzer (1996). Perbandingan Kebijakan Alokasi Disk FFS . Prosiding Konferensi Teknis Tahunan USENIX. Diarsipkan di harvard.edu.
• Steve D. Pate (2003). "Analisis kinerja FFS". Sistem File UNIX: Evolusi, Desain, dan Implementasi . John Wiley amp; Anak-anak ISBN 9780471456759.
• Amir H. Majidimehr (1996). Mengoptimalkan UNIX untuk Performa . Prentice Hall. ISBN 9780131115514.
• Bill Calkins (2002). "Mengelola Sistem File". Di dalam Solaris 9 . Que Publishing. ISBN 9780735711013.
• Anand Lal Shimpi (2012-10-04). Menjelajahi Hubungan Antara Area Cadangan dan Konsistensi Kinerja di SSD Modern . AnandTech.
• Henry Cook, Jonathan Ellithorpe, Laura Keys, dan Andrew Waterman (2010). IotaFS: Menjelajahi Optimalisasi Sistem File untuk SSD . Transaksi IEEE pada Elektronik Konsumen. Diarsipkan di stanford.edu.
• https://superuser.com/a/1081730/38062
• Accela Zhao (2017-04-10). Ringkasan tentang SSD & FTL . github.io.
• Apakah Windows memangkas ruang tanpa partisi (tidak diformat) pada SSD?

Meskipun saya tidak dapat berbicara tentang "penelitian" yang diterbitkan oleh "jurnal peer-review" - dan saya tidak ingin harus bergantung pada itu untuk pekerjaan sehari-hari - saya dapat berbicara tentang realitas ratusan produksi server di bawah berbagai OS selama bertahun-tahun:

Ada tiga alasan mengapa disk penuh mengurangi kinerja:

• Kelaparan ruang bebas: Pikirkan file temp, Pembaruan, dll.
• Degradasi sistem file: Sebagian besar sistem file menderita karena kemampuannya untuk menata file secara optimal jika tidak tersedia cukup ruang
• Degradasi tingkat perangkat keras: SSD dan disk SMR tanpa ruang kosong yang cukup akan menunjukkan throughput yang menurun dan - bahkan lebih buruk - peningkatan latensi (kadang-kadang oleh banyak urutan besarnya)

Poin pertama adalah sepele, terutama karena tidak ada sistem produksi waras yang akan menggunakan ruang swap dalam memperluas dan menyusutkan file secara dinamis.

Poin kedua sangat berbeda antara sistem file dan beban kerja. Untuk sistem Windows dengan beban kerja campuran, ambang batas 70% ternyata cukup bermanfaat. Untuk sistem file Linux ext4 dengan sedikit tetapi file besar (misalnya sistem siaran video), ini mungkin naik hingga 90%.

Poin ketiga bergantung pada perangkat keras dan firmware, tetapi terutama SSD dengan pengontrol Sandforce dapat jatuh kembali pada penghapusan blok-bebas pada beban kerja tulis tinggi, yang menyebabkan latensi tulis meningkat hingga ribuan persen. Kami biasanya membiarkan 25% gratis di tingkat partisi, lalu mengamati tingkat pengisian di bawah 80%.

Rekomendasi

Saya menyadari bahwa saya menyebutkan cara memastikan tingkat pengisian maksimum diberlakukan. Beberapa pemikiran acak, tidak satu pun dari mereka "peer review" (berbayar, palsu atau nyata) tetapi semuanya dari sistem produksi.

• Gunakan batasan filesystem: /vartidak termasuk dalam sistem file root.
• Pemantauan, pemantauan, pemantauan. Gunakan solusi yang sudah jadi jika cocok untuk Anda, jika tidak parsing output df -hdan lonceng alarm berjaga-jaga. Ini dapat menyelamatkan Anda dari 30 kernel pada root fs dengan pemutakhiran otomatis diinstal dan berjalan tanpa opsi autoremove.
• Timbang potensi gangguan overflow fs terhadap biaya membuatnya lebih besar di tempat pertama: Jika Anda tidak pada perangkat tertanam, Anda mungkin hanya menggandakan 4G untuk root.

Apakah ada penelitian ... ke dalam persentase atau jumlah absolut ruang bebas yang diperlukan oleh kombinasi spesifik sistem operasi, sistem file, dan teknologi penyimpanan ...?

Dalam 20 tahun administrasi sistem, saya belum pernah menemukan penelitian yang merinci persyaratan ruang bebas berbagai konfigurasi. Saya menduga ini karena komputer sangat beragam dikonfigurasi sehingga akan sulit dilakukan karena banyaknya kemungkinan konfigurasi sistem.

Untuk menentukan berapa banyak ruang kosong yang dibutuhkan sistem, seseorang harus memperhitungkan dua variabel:

1. Ruang minimum yang diperlukan untuk mencegah perilaku yang tidak diinginkan, yang dengan sendirinya mungkin memiliki definisi yang lancar.

   Perhatikan bahwa mendefinisikan ruang kosong yang diperlukan dengan definisi ini saja tidak membantu, karena itu sama dengan mengatakan bahwa aman untuk mengarahkan 80 mph ke arah dinding bata hingga titik di mana Anda bertabrakan dengannya.

2. Tingkat penyimpanan yang digunakan, yang menentukan jumlah variabel tambahan ruang dicadangkan, jangan sampai sistem menurun sebelum admin punya waktu untuk bereaksi.

Kombinasi spesifik dari OS, sistem file, arsitektur penyimpanan yang mendasarinya, bersama dengan perilaku aplikasi, konfigurasi memori virtual, dll. Menciptakan tantangan yang cukup bagi seseorang yang ingin memberikan persyaratan ruang bebas yang pasti.

Itu sebabnya ada begitu banyak "nugget" saran di luar sana. Anda akan melihat bahwa banyak dari mereka membuat rekomendasi seputar konfigurasi tertentu. Misalnya, "Jika Anda memiliki SSD yang mengalami masalah kinerja saat mendekati kapasitas, tetap di atas ruang kosong 20%."

Karena tidak ada jawaban sederhana untuk pertanyaan ini, pendekatan yang tepat untuk mengidentifikasi kebutuhan ruang kosong minimum sistem Anda adalah dengan mempertimbangkan berbagai rekomendasi umum berdasarkan konfigurasi spesifik sistem Anda, kemudian menetapkan ambang batas, memantau, dan bersedia menyesuaikannya seperlunya.

Atau Anda bisa menjaga setidaknya 20% ruang kosong. Kecuali tentu saja Anda memiliki volume 42 TB RAID 6 yang didukung oleh kombinasi SSD dan hard disk tradisional dan file swap yang dialokasikan sebelumnya ... (itu lelucon bagi orang-orang yang serius.)

Tentu saja, drive itu sendiri (HDD atau SSD) tidak peduli tentang berapa persen yang digunakan, selain SSD dapat menghapus ruang kosong mereka untuk Anda sebelumnya. Performa baca akan persis sama, dan kinerja penulisan mungkin agak buruk pada SSD. Bagaimanapun, kinerja menulis tidak begitu penting pada drive yang hampir penuh, karena tidak ada ruang untuk menulis apa pun.

OS Anda, sistem file dan aplikasi di sisi lain akan mengharapkan Anda memiliki ruang kosong yang tersedia setiap saat. 20 tahun yang lalu itu adalah khas untuk aplikasi untuk memeriksa berapa banyak ruang yang Anda miliki di drive sebelum mencoba menyimpan file Anda di sana. Hari ini, aplikasi membuat file sementara tanpa meminta izin Anda, dan biasanya macet atau berperilaku tidak menentu ketika mereka gagal melakukannya.

Filesystem memiliki harapan yang sama. Sebagai contoh, NTFS menyimpan sebagian besar disk Anda untuk MFT, tetapi masih menunjukkan ruang ini sebagai gratis. Ketika Anda mengisi disk NTFS Anda di atas 80% dari kapasitasnya, Anda mendapatkan fragmentasi MFT yang memiliki dampak yang sangat nyata pada kinerja.

Selain itu, memiliki ruang kosong memang membantu melawan fragmentasi file biasa. Filesystem cenderung menghindari fragmenasi file dengan mencari tempat yang tepat untuk setiap file tergantung pada ukurannya. Pada disk yang hampir diisi, mereka akan memiliki lebih sedikit opsi, sehingga mereka harus membuat pilihan yang lebih buruk.

Di Windows, Anda juga diharapkan memiliki ruang disk yang cukup untuk file swap , yang dapat tumbuh bila diperlukan. Jika tidak bisa, Anda harus mengharapkan aplikasi Anda ditutup secara paksa. Memiliki sedikit ruang swap memang dapat memperburuk kinerja.

Bahkan jika swap Anda memiliki ukuran tetap, kehabisan ruang disk sistem dapat membuat sistem Anda crash dan / atau membuatnya tidak dapat di-boot (sama seperti Windows dan Linux), karena OS akan dapat menulis ke disk saat boot. Jadi ya, memukul 90% dari penggunaan disk harus membuat Anda menganggap cat Anda terbakar. Tidak sekali pun saya melihat komputer yang gagal mem-boot dengan benar sampai unduhan terakhir dihapus untuk memberi OS sedikit ruang disk.

Untuk SSD harus ada ruang yang tersisa karena laju penulisan ulang kemudian meningkat dan secara negatif mempengaruhi kinerja penulisan disk. 80% penuh adalah nilai aman yang mungkin untuk semua disk SSD, beberapa model terbaru dapat bekerja dengan baik bahkan dengan kapasitas yang ditempati 90-95%.

https://www.howtogeek.com/165542/why-solid-state-drives-slow-down-down-as-you-fill-them-up/

"Aturan" bervariasi tergantung pada kebutuhan Anda. Dan ada beberapa kasus khusus, seperti, misalnya ZFS: "Pada kapasitas 90%, ZFS beralih dari pengoptimalan berbasis kinerja ke ruang, yang memiliki implikasi kinerja besar-besaran.". Ya, ini adalah aspek desain ZFS ... bukan sesuatu yang diturunkan melalui pengamatan atau bukti anekdotal. Jelas, ini bukan masalah jika kumpulan penyimpanan ZFS Anda hanya terdiri dari SSD. Namun, bahkan dengan disk pemintalan, Anda dapat dengan senang hati mencapai 99% atau 100% ketika Anda berurusan dengan penyimpanan statis dan Anda tidak memerlukan kinerja terbaik - misalnya, koleksi film favorit pribadi sepanjang masa, yang tidak pernah berubah dan di mana keselamatan adalah prioritas 1.

Selanjutnya, btrfs - kasus ekstrem: ketika ruang kosong menjadi terlalu rendah (beberapa MByte), Anda dapat mencapai titik tidak dapat kembali. Tidak, menghapus file bukan opsi, karena Anda tidak bisa. Tidak ada cukup ruang untuk menghapus file. btrfs adalah sistem file COW (copy-on-write), dan Anda dapat mencapai titik di mana Anda tidak dapat memodifikasi metadata lagi. Pada titik ini, Anda masih dapat menambahkan penyimpanan tambahan ke sistem file Anda (USB thumb drive mungkin berfungsi), kemudian menghapus file dari sistem file yang diperluas, kemudian mengecilkan sistem file dan menghapus penyimpanan tambahan lagi). Sekali lagi, ini adalah beberapa aspek yang disebabkan oleh desain sistem file.

Orang yang dapat memberi Anda "data nyata (serius)" mungkin adalah orang-orang yang berurusan dengan penyimpanan "nyata (serius)". Jawaban Twisty (luar biasa) menyebutkan array hybrid (terdiri dari sejumlah besar pemintalan lambat murah, banyak cakram pemintalan cepat, banyak SSD ...) yang dioperasikan dalam lingkungan perusahaan di mana faktor pembatas utamanya adalah kecepatan di mana admin berada dapat memesan upgrade. Beralih dari 16T menjadi 35T bisa memakan waktu 6 bulan ... sehingga Anda berakhir dengan laporan yang didukung serius yang menyarankan untuk mengatur alarm Anda hingga 50%.

Ada banyak, banyak faktor yang berkontribusi pada hasil dalam jumlah yang sangat spesifik. Jadi, tidak ada angka yang sulit dan cepat, ini hanya dapat diukur sebagai fungsi dari parameter tersebut. (Mungkin itulah sebabnya pengguna lain melaporkan tidak ada penelitian khusus tentang subjek khusus ini - terlalu banyak variabel untuk mengkompilasi sesuatu yang konklusif.)

• Perangkat keras

  • HDD memiliki semua sektornya yang dialokasikan setiap saat. Jadi sama sekali tidak peduli berapa banyak dari mereka yang berisi data pengguna saat ini. (Untuk controller, semua sektor berisi beberapa data setiap saat, hanya membaca dan menimpanya seperti yang diperintahkan.)
  • Pengontrol SSD, di sisi lain, (de) mengalokasikan sektornya secara dinamis, mirip dengan sistem file. Yang membuat pekerjaan ini lebih sulit dengan penggunaan yang lebih tinggi. Seberapa sulit dan seberapa besar ini mempengaruhi kinerja yang dapat diamati tergantung pada:
    • Kinerja dan kualitas algoritme pengontrol
    • Tulis beban
    • Pada tingkat tertentu, beban keseluruhan (untuk memberi waktu pengontrol untuk pengumpulan sampah)
    • Space overprovision (beberapa produsen bahkan membiarkan pelanggan memilihnya pre-order atau berubah secara dinamis)

• Berkas sistem

  • Sistem file yang berbeda dirancang untuk beban yang berbeda dan persyaratan pemrosesan host. Ini dapat disesuaikan dengan parameter format.
  • Kinerja tulis FS adalah fungsi ruang kosong dan fragmentasi, kinerja baca adalah fungsi fragmentasi saja. Ini menurun secara bertahap sejak awal, jadi pertanyaannya adalah di mana letak batas toleransi Anda.

• Jenis beban

  • Beban menulis sangat menekankan untuk menemukan dan mengakses blok-blok baru secara cepat
  • Beban baca-berat menekankan konsolidasi data terkait sehingga dapat dibaca dengan lebih sedikit overhead

Satu hal yang perlu dipertimbangkan dengan drive mekanis adalah bahwa keluaran tepi luar lebih tinggi daripada bagian dalam. Ini karena ada lebih banyak sektor per revolusi untuk lingkar luar yang lebih besar.

Ketika drive mencapai kapasitas, kinerja akan menurun karena hanya sektor dalam yang lebih lambat akan tersedia.

Untuk analisis lebih mendalam, lihat https://superuser.com/a/643634

Itu tergantung pada penggunaan drive yang dimaksud, tetapi secara umum 20% hingga 15% ruang kosong adalah jawaban yang baik untuk memutar disk, dan 10% atau lebih bagus untuk SSD.

Jika ini adalah drive utama di komputer dan file dapat dipindahkan, maka ruang kosong 20% ​​harus mencegah perlambatan yang signifikan. Ini akan memungkinkan ruang terbuka yang cukup di seluruh drive untuk data untuk dipindahkan dan disalin sesuai kebutuhan. Drive pemintalan akan bekerja paling baik ketika lokasi bebas lebih dekat dengan data asli, sementara di SSD lokasi fisik tidak memengaruhi kinerja harian. Jadi, drive pemintalan harus memiliki lebih banyak ruang kosong karena alasan kinerja semata. Pada SSD, ruang kosong yang berkurang akan mengurangi umur drive, tetapi tidak akan mengurangi kinerja. SSD mencoba menyimpan data sementara dan file unduhan acak di lokasi yang paling jarang digunakan sehingga mereka dapat menyeimbangkan penggunaan sel di seluruh drive; jika tidak, sebagian drive akan menua lebih cepat daripada yang lain.

Jika ini adalah media atau drive penyimpanan jangka panjang, maka 5% hingga 10% gratis sudah cukup, dan 10% lebih disukai jika itu adalah disk pemintalan. Anda tidak memerlukan banyak ruang kosong karena drive ini jarang membutuhkan data untuk dipindahkan, sehingga kinerja bukanlah faktor yang hampir sama. Ruang kosong berguna terutama untuk memungkinkan bad sector dibuang dan diganti, dan untuk memungkinkan file menjadi lebih berdekatan.

Saya tidak akan mendorong drive melebihi kapasitas 95% selama lebih dari satu hari kecuali ada alasan yang sangat bagus dan jelas.