Disk yang Terlalu Penuh hingga Tidak Bisa Dipulihkan

 (sixcolors.com)
2 poin oleh GN⁺ 2024-04-05 | 1 komentar | Bagikan ke WhatsApp
  • Volume startup pada M2 MacBook Pro menjadi begitu penuh saat mengunduh game Steam hingga hanya tersisa 41KB, membuat macOS bahkan tidak bisa menghapus file
  • Mengosongkan Trash di Finder, rm dan find -exec rm di Terminal, hingga menghapus snapshot Time Machine di Disk Utility semuanya gagal dengan galat sejenis “No space left on device”
  • Setelah restart, proses boot juga berhenti di tengah jalan, dan meski dipasang ke Mac lain melalui recoveryOS serta Share Disk di Apple silicon, penghapusan tetap tidak bisa dipaksakan
  • Setelah menghapus drive dan menginstal ulang macOS, upaya pemulihan Time Machine juga terkendala: pemulihan Ventura terhenti, ada perbedaan versi antara Sonoma 14.4 dan 14.3.1 yang lama, serta mount jaringan SMB/Samba gagal
  • Pada akhirnya, image disk Time Machine terbaru disalin ke SSD eksternal 1TB dan file direktori home serta aplikasi dipulihkan secara manual; jika kehabisan ruang penyimpanan bertumpuk dengan kegagalan pemulihan backup, bahkan pengguna berpengalaman pun sulit menanganinya

Mac yang Kehabisan Ruang hingga Penghapusan pun Terhalang

  • Ruang penyimpanan M2 MacBook Pro penuh saat mengunduh game yang dibeli secara legal dari Steam
  • macOS tidak menghentikan unduhan Steam berukuran besar meski drive sudah sangat berbahaya penuhnya, dan volume startup hanya menyisakan 41KB
  • Sebagian besar file penting berada di cloud, dan tidak ada keharusan untuk mempertahankan file lokal berukuran besar
  • Masalahnya bukan sekadar kekurangan kapasitas, melainkan kondisi ketika sistem operasi tidak bisa menghapus file dengan cara apa pun

Penyebab yang Dicurigai: Unduhan Steam dan Snapshot Time Machine Lokal

  • Ada kemungkinan macOS tidak mampu mengendalikan pertambahan penggunaan penyimpanan karena koneksi internet gigabit dan file Steam berukuran besar
  • Pada saat yang sama, dicurigai bahwa macOS sedang membuat snapshot Time Machine lokal
  • macOS mempertahankan snapshot untuk menyediakan backup lokal 24 jam terakhir, bahkan saat sedang melakukan backup ke target Time Machine eksternal atau jaringan
  • File Steam dari luar tampak seperti satu file raksasa, tetapi dari sudut pandang Time Machine mungkin diperlakukan berbeda
  • Bisa jadi file lokal yang sebenarnya berbenturan dengan snapshot yang dibuat secara khusus, tetapi penyebab pastinya belum dapat dipastikan

Semua Upaya Penghapusan Gagal

  • Mengosongkan Trash di Finder gagal melalui File > Empty Trash
    • Pesan galatnya adalah “The operation can’t be completed because the disk is full”
  • Terminal bisa dijalankan, tetapi perintah Unix standar rm tidak berfungsi
    • Pesan galatnya adalah “No space left on device”
    • Alternatif berbasis find yang mencari file besar lalu menjalankan rm dengan opsi -exec juga gagal
  • Di Disk Utility, upaya memilih dan menghapus snapshot Time Machine pada volume startup APFS juga terhalang batasan yang sama
    • Secara umum, snapshot hanya memakai ruang penyimpanan yang diperlukan untuk perbedaan dari snapshot sebelumnya
    • Dalam kasus ini pun muncul galat “no space left”

Restart, recoveryOS, dan Share Disk Juga Tidak Berhasil

  • Restart dilakukan dengan harapan cache akan dibersihkan, tetapi Mac tidak lagi bisa boot secara normal
  • Kondisi berulang: progress bar berjalan hingga sekitar setengah, lalu gagal
  • Di recoveryOS, saat volume startup tidak ter-mount, perbaikan Disk Utility dan pekerjaan terkait instalasi ulang dicoba, tetapi perintah Terminal menghasilkan galat yang sama
  • Dengan fitur Share Disk pada Apple silicon, drive tersebut dicoba di-mount ke Mac lain
    • Upaya memaksa penghapusan melalui berbagi disk berbasis Samba gagal

Hambatan Berlanjut Saat Pemulihan Time Machine

  • Tersedia backup Time Machine termasuk backup dari malam sebelumnya, dan karena sebagian besar data penting berada di cloud, pemulihan penuh tidak terlalu dipaksakan
  • Pertama, drive dihapus dan melalui macOS Recovery diinstal ulang Ventura, sistem bawaan saat MacBook Pro keluar dari pabrik
  • Saat macOS mulai berjalan, Migration Assistant digunakan untuk mengakses backup Time Machine jaringan, dan beberapa item pemulihan dinonaktifkan agar menyisakan ruang penyimpanan yang cukup
  • Di tengah proses pemulihan, Ventura terhenti dan setelah itu tidak bisa dilanjutkan
  • Setelah itu Mac di-upgrade ke Sonoma, macOS yang saat itu digunakan
    • Upgrade berhasil, tetapi versi yang terpasang adalah 14.4
    • Mac sebelumnya menjalankan 14.3.1
    • Saat mencoba memulihkan langsung pada tahap awal, proses tidak diizinkan karena perbedaan versi

Masalah Mount Time Machine Jaringan di Sonoma 14.4

  • Setelah membuat akun pengguna Sonoma dasar, Migration Assistant dijalankan
  • Migration Assistant menemukan dan mengenali Mac jaringan yang mengelola backup Time Machine
  • Namun volume backup milik anak tidak bisa di-mount, dan berulang kali muncul “Mount failed”
  • Hasil pencarian forum menunjukkan bahwa di Sonoma, prosedur mount jaringan berbasis SMB/Samba untuk pemulihan Time Machine rusak, dan belum ditemukan solusi
  • Masalah ini tampaknya masih berlaku di macOS 14.4

Pemulihan Akhir: Menyalin Backup ke SSD Eksternal dan Memindahkan Manual

  • Pemulihan lengkap lewat Migration Assistant ditinggalkan, dan hanya aplikasi serta file yang diperlukan yang dipulihkan secara manual
  • Di Mac yang mengelola backup jaringan, image disk komputer tersebut diklik dua kali dan kata sandi volume Time Machine dimasukkan
    • Volume Time Machine jaringan memang selalu diberi kata sandi terpisah
  • Ikon disk dengan timestamp terbaru dicari, lalu disalin ke SSD eksternal 1TB kosong
  • SSD eksternal dihubungkan ke akun sementara di MacBook Pro untuk memindahkan file yang diperlukan
    • Sebagian besar isi folder direktori home tercakup
    • File unduhan besar dan sebagian file video yang tidak diperlukan dikecualikan
  • SSD eksternal akan disimpan sementara agar bisa dipakai untuk pemulihan tambahan jika ada file yang hilang

Alternatif yang Tidak Sempat Dicoba

  • Drive Time Machine untuk backup jaringan sebenarnya bisa di-unmount dari Mac pengelola backup lalu dihubungkan langsung ke Mac milik anak
    • Dalam kasus ini, drive tersebut mungkin muncul sebagai titik awal di Migration Assistant
  • Virtual disk dari image disk Time Machine yang sudah di-mount juga bisa disalin agar SSD eksternal 1TB terlihat seperti volume sumber Mac
    • Belum dipastikan apakah cara ini benar-benar akan berfungsi
    • Jika berhasil, ada kemungkinan pemulihan langsung melalui Migration Assistant bisa dilakukan
  • Karena sudah terkumpul beberapa jam kerja dan lebih dari sehari upaya, serta pengguna tidak terlalu menginginkan pemulihan sempurna per direktori, eksperimen tambahan tidak dilakukan

Bacaan terkait

1 komentar

 
GN⁺ 2024-04-05
Komentar Hacker News

  • Mungkin akan lebih baik jika penulis mem-boot Mac dari perangkat penyimpanan eksternal lalu menghapus file yang tidak diperlukan dari disk internal: Use an external storage device as a Mac startup disk
    Yang mengejutkan, pada Mac berbasis Apple Silicon, tidak semua port setara saat melakukan boot eksternal
    Saat memasang macOS ke perangkat penyimpanan, laptop Mac harus menghindari port USB-C paling kiri di antara port sebelah kiri, dan iMac/Mac mini/Mac Studio/Mac Pro juga punya port USB-C tertentu yang harus dihindari tergantung modelnya
    Setelah instalasi selesai, katanya perangkat bisa dihubungkan ke port mana pun

    • Penulis sebenarnya sudah mencoba sesuatu yang pada dasarnya sama dengan saran itu
      Penulis mem-boot ke recoveryOS, yang merupakan partisi terpisah, lalu mencoba menghapus file dari partisi sistem utama, tetapi rm gagal dengan error yang sama: No space left on device
      Jadi seperti yang dikatakan orang lain, cara memotong file dengan echo -n >file mungkin saja berhasil
    • Jika filesystem itu sendiri sudah masuk deadlock, menghapus file melalui driver filesystem tidak akan berhasil, dari mana pun Anda boot
    • recoveryOS maupun mode Mac Share Disk/Target Disk juga tidak berhasil, jadi penasaran kenapa cara itu dianggap akan berhasil
    • Komentar seperti ini akan sangat disambut oleh seseorang yang 8 tahun kemudian mencari solusi untuk masalah Mac yang saat itu sudah tua
    • Penasaran apakah ada yang tahu kenapa saat membuat OS yang bisa di-boot di laptop Mac, port USB-C pertama tidak boleh digunakan

  • Dengan sedikit pengetahuan tentang struktur disk HFS+, saya menduga file journal juga penuh, dan karena penghapusan perlu menulis ke journal serta dalam beberapa kasus memperluasnya, sepertinya ini menjadi kondisi aneh ketika penghapusan itu sendiri membutuhkan lebih banyak ruang, meski hanya sementara
    macOS terus menulis file sampai hanya tersisa 41KB di drive
    Saya pernah tanpa sengaja mengisi NTFS dan FAT32 sampai 0 byte, tetapi saat itu menghapus sesuatu masih bisa dilakukan
    Setelah menelusuri forum, tampaknya Sonoma merusak prosedur network mount berbasis SMB/Samba untuk pemulihan Time Machine, dan di 14.4 pun sepertinya belum ada solusinya
    Berdasarkan pengalaman, SMB sudah sulit dipercaya dan terlalu banyak bug sejak sekitar 10.12–10.13, dan sekarang Apple tampaknya bahkan tidak peduli apakah ini berfungsi atau tidak
    Saya tidak ingin membayangkan apa yang akan dilakukan orang tanpa pengalaman puluhan tahun menggunakan Mac ketika menghadapi rangkaian kegagalan sistem seperti ini
    Saya tidak punya pengalaman puluhan tahun menggunakan Mac, tetapi dalam situasi seperti ini saya akan mencoba fsck lebih dulu, jadi aneh bahwa itu tidak disebutkan di sini
    Jika isi disk tidak bisa disalin ke disk lain lalu diformat dan dikembalikan, saya mungkin akan melihat dokumentasi APFS (https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf) dan mencari dengan dd serta editor heksadesimal bagian mana yang perlu diperbaiki untuk membuat ruang kosong

    • Itu berlaku untuk filesystem berjurnal, sedangkan pada filesystem copy-on-write (CoW), setiap perubahan dilakukan dengan membuat pohon file baru lalu membuat root menunjuk ke pohon baru tersebut
      Setelah itu garbage collection mencari file yang tidak lagi termasuk dalam pohon aktif dan mengembalikannya menjadi ruang penyimpanan
      Biasanya perubahan dikelompokkan agar jumlah perubahan pohon tetap pada tingkat yang dapat dikelola, dan berkat desain ini, snapshot filesystem menjadi referensi lain ke pohon tertentu
      Proses ini membutuhkan ruang, tetapi filesystem CoW biasanya mencadangkan ruang penyimpanan darurat khusus untuk alasan seperti ini
    • Apple sudah lama beralih ke implementasinya sendiri setelah Samba mengadopsi GPLv3: https://lists.samba.org/archive/samba-announce/2007/000122.html, https://www.engadget.com/2011-03-24-apple-to-drop-samba-networking-tools-from-lion.html
    • Seperti khas Apple, performa SMB beberapa tahun lalu terasa sangat lambat, dan bahkan belakangan ini baru sebatas lumayan saja; masih jauh lebih lambat daripada NFS pada hardware yang sama, atau ironisnya, Appleshare
      Beberapa tahun lalu, saat mengukur dengan BlackMagic Disk Speed Test di Hackintosh yang terhubung ke NAS besar lewat 10GbE, SMB di Windows mencapai 900MB/s, SMB di macOS 200MB/s, sedangkan NFS dan AFP di macOS sama-sama 1000MB/s
      Fitur macOS yang terkait pekerjaan profesional sayangnya berada pada level yang menggelikan
      Orang bilang AFP sudah mati, tetapi di Mac Pro saya, sebagai klien, ia masih berjalan baik, dan performanya jauh lebih bagus daripada SMB sampai terasa hampir seperti komedi
    • Tidak lucu kalau mengalaminya sendiri, tetapi hal yang sama juga bisa terjadi pada BTRFS dan ZFS
      Jika diisi sampai benar-benar penuh, masalah bisa muncul
      BTRFS mencoba beralih ke mode read-only saat ruang metadata masih tersisa, sehingga bisa di-mount ulang dalam safe mode dan memungkinkan sesuatu dihapus, tetapi tidak ada perlindungan yang sempurna
      Sejauh yang saya tahu, NTFS dan FAT32 bukan filesystem berjurnal
    • Sejauh ini, ini tampaknya satu-satunya penjelasan teknis yang benar-benar memadai

  • Saya pernah mengalami hal seperti ini di pekerjaan pertama saya
    Secara tidak sengaja saya memenuhi klaster dengan file job, lalu sysadmin mulai mengirim email agar saya segera memperbaikinya, tetapi rm tidak berfungsi
    Saat itu saya belajar bahwa meski penghapusan tidak bisa dilakukan, memotong file biasanya masih bisa, jadi ketika rm foo gagal, sering kali cat /dev/null > foo bisa dipakai

    • Di shell, :>filepath sering berhasil
      Namun beberapa filesystem mungkin bahkan tidak bisa melakukan itu
      Dalam kasus seperti itu, Anda hanya bisa berharap filesystem mendukung perluasan ukuran, penyusutan ukuran, atau ruang penyimpanan tambahan sementara, atau subsistem di bawahnya memungkinkan backing storage ditambah/dihapus
      Seperti btrfs, mungkin perlu perintah terpisah untuk mengembalikannya ke struktur bagi satu perangkat blok
    • Beberapa tahun lalu, ada situasi ketika infrastruktur inti yang harus selalu bisa menulis ke filesystem dapat mengalami deadlock dan rusak tanpa bisa dipulihkan
      Jadi proses backup dibuat secara berkala mengirim data sampah langsung ke /dev/null, dan mungkin hack kotor itu masih berjalan sampai sekarang
      /dev/null terasa seperti sihir dan layak dibaca sekali
    • Sebenarnya cukup >file saja juga bisa
    • Namun seperti banyak komentar di sini, ada juga situasi ketika memotong pun gagal
      Format filesystem abad ke-21 jauh lebih kompleks daripada UFS, dan fitur seperti snapshot serta journaling menciptakan cara-cara baru bagi filesystem untuk mengalami deadlock sendiri
    • Saya pernah mengatur level log Samba terlalu tinggi untuk debugging lalu lupa mengembalikannya, hingga SSD root ZFS penuh oleh file log raksasa
      Pada akhirnya harus dipulihkan dengan truncate
      Saya tahu ZFS lebih baik dalam situasi seperti ini, tetapi rasa tenggelam “ah… sial” ketika benar-benar merasa telah mengacaukannya tetap sama

  • Time Machine tampaknya terus memburuk
    Saya tidak mengerti mengapa tidak ada dorongan untuk membuatnya stabil dan berfungsi dengan benar
    Setelah mengalami sparse bundle rusak sehingga harus memulai backup baru, atau fiturnya gagal, sekarang saya merasa Time Machine tidak terlalu layak disetel
    Ini sangat kontras dengan backup iOS/iPadOS yang selalu berjalan baik setiap kali

    • Karena mereka tidak lagi menjual Time Capsule
      Apple ingin orang-orang mencadangkan semuanya ke iCloud untuk meningkatkan pendapatan layanan
    • Dari sudut pandang orang yang tidak memakai Mac, ini terdengar seperti bug katastrofik yang tidak bisa dimaafkan yang akan menuai kecaman besar kalau terjadi pada sistem operasi desktop dengan maskot penguin atau yang berkantor pusat di Washington
    • Sudah terlalu sering Time Machine tiba-tiba memutuskan tidak mau bekerja lagi, sehingga backup harus dihapus dan dimulai dari awal
    • Kontrol kualitas macOS telah menurun sejak Scott Forstall dipecat, dan sebenarnya pada masanya pun tidak sampai mengesankan
    • Pengalaman saya berbeda
      Saya telah menjalankan Time Machine di atas share Samba pada beberapa Mac selama bertahun-tahun, dan justru hanya melihat perbaikan
      Dulu sparse bundle Time Machine sering rusak sehingga harus dibuat ulang, atau harus memulihkan snapshot ZFS sebelumnya untuk melanjutkan
      Seingat saya waktu itu masih AFP, bukan SMB
      Belakangan ini tidak ada masalah seperti itu di perangkat mana pun, dan saya memang mengaktifkan flag tertentu yang direkomendasikan untuk backup Time Machine di smb.conf

  • Sebaliknya, ZFS memiliki slop space untuk menghindari filesystem macet karena kehabisan ruang di tengah operasi besar
    Secara default, ia mencadangkan 3,2% ruang volume hingga maksimum 128GB
    Jadi dengan mengubah nilai tuning kernel Linux spa_slop_shift untuk mengurangi slop space, Anda bisa mendapatkan kembali hingga 128GB ruang bonus agar operasi penghapusan file berhasil selesai: https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#spa-slop-shift

    • Benar
      Karena alasan seperti ini, fitur untuk mencadangkan persentase tertentu dari ruang disk sudah menjadi fitur umum filesystem “sungguhan” puluhan tahun sebelum ZFS atau Linux ada
      Ini mirip dengan bagaimana kebanyakan program terminal shareware MS-DOS tahun 1980-an sangat baik menangani pengunduhan file lewat koneksi bandwidth terbatas, sementara MS Windows saat ini buruk bahkan untuk tugas yang seharusnya sepele seperti itu
    • ext4 juga punya fitur yang sama, hanya saja namanya reserved blocks
      Untuk detailnya, lihat man tune2fs
      Sebagian besar filesystem modern maupun yang tidak terlalu modern lainnya juga demikian
      Seingat saya, UFS di SunOS tahun 1980-an juga begitu: https://en.wikipedia.org/wiki/SunOS

  • Orang sulit memahami konsep bahwa menghapus sesuatu bisa benar-benar membutuhkan lebih banyak ruang, baik sementara maupun permanen
    Komentar lain sudah membahas secara rinci mengapa filesystem modern seperti yang memakai snapshot dan journaling perlu mengalokasikan ruang kosong untuk melakukan penghapusan
    Di bidang lain pun mirip: selama 10 tahun awal Wikipedia, sering harus dijelaskan bahwa upaya menghapus halaman untuk menghemat ruang server justru memberi efek sebaliknya
    Setidaknya sejak sekitar 2004, penghapusan menambahkan record ke database internal
    Dalam format arsip ZOO buatan Rahul Dhesi, menghapus entri hanya berarti menandai flag pada record header, dan ada juga versioning file ala VMS yang tidak menimpa versi lama meski versi baru ditambahkan
    Pada masa MS/DR/PC-DOS dan FAT, jika utilitas pemulihan penghapusan terpasang, penghapusan file bisa membutuhkan lebih banyak ruang karena harus menyimpan entri baru di database berisi informasi pemulihan
    Beberapa utilitas kompresi disk lama bahkan mengompresi metadata, sehingga dalam kasus langka, perubahan metadata bisa mengubah rasio kompresi dan benar-benar memperbesar ukuran volume yang terlihat dari luar
    Gagasan bahwa menghapus akan mengosongkan ruang memang tersebar luas, tetapi secara ketat tidak selalu benar

  • Saya pernah mengalami masalah yang sama pada Oktober 2018, dan meninggalkannya di pertanyaan Stack Overflow di bawah ini.
    Untungnya ada partisi APFS tambahan yang bisa saya hapus, sehingga saya bisa mengosongkan ruang disk.
    Butuh waktu cukup lama untuk mengetahuinya, dan selama itu saya benar-benar panik.
    https://apple.stackexchange.com/questions/338721/disk-full-terminal-in-recovery-mode-won-t-delete-files-boot-kernel-panics
    Tepat setelah memperbarui macOS Mojave, saya memenuhi disk saat membuat .dmg dan sistem membeku.
    Setelah reboot, terjadi kernel panic; saya lalu boot ke recovery mode, me-mount disk, dan menjalankan rm /path/to/large/file dari terminal, tetapi muncul No space left on device.
    Pada dasarnya ini masalah yang sama dengan thread Unix dari 2008: https://www.unix.com/linux/69889-unable-remove-file-using-rm-disk-space-full.html
    echo x > /path/to/large/file juga tidak membantu, dan saya butuh saran lain selain “hapus drive dan pulihkan dari backup”.

    • Membuat partisi tambahan kecil sekitar 1GB mungkin bisa menjadi semacam asuransi yang bagus.
      Mirip dengan filesystem Unix lama yang mencadangkan 5% untuk root.
    • Di tulisan StackExchange itu kemudian ada beberapa solusi potensial lain.
      Jika partisi memori virtual dihapus, dengan asumsi ukurannya cukup besar, ruang yang dikembalikan bisa cukup untuk memungkinkan penghapusan file.
    • Di APFS, hal itu tidak sesederhana itu.
      Karena container baru dialokasikan hanya saat benar-benar dipakai.

  • Mengesankan.
    Saya belum pernah mengalami situasi sampai rm pun gagal, tetapi pernah merasakan tidak enaknya memakai dan mengelola Mac modern dengan penyimpanan internal 256GB atau kurang.
    Karena itu saya biasanya membuat file placeholder berukuran sekitar 16GB.
    Jadi kalau ruang terlanjur penuh sampai menghalangi update atau pekerjaan lain, saya cukup menghapus file itu tanpa perlu melakukan pembersihan seperti operasi bedah dengan ncdu.

  • Saya juga pernah mengalami hal serupa di iPhone.
    Disk terlalu penuh sehingga meskipun saya menghapus sesuatu, tampaknya tidak ada yang benar-benar terjadi.
    Setelah reboot, saya tidak bisa login; setelah reboot lagi, perangkat masuk boot loop.
    Setelah reboot sekali lagi, perangkat berhasil masuk ke home screen dalam keadaan tidak konsisten: ikon aplikasi masih ada, tetapi aplikasi sebenarnya hilang, ikonnya kosong, dan tidak bisa dijalankan.
    Karena khawatir soal integritas data, akhirnya saya memulihkan dari backup.
    Saya yakin ini terjadi karena APFS memakai copy-on-write dan mendukung snapshot.
    Jika perubahan tidak langsung diterapkan secara permanen dan versi lama file tetap tersimpan di snapshot, situasinya jadi sulit saat bahkan tidak ada ruang untuk metadata snapshot.
    Saat ruang disk kurang, snapshot mungkin saja dilewati, tetapi masalah metadata CoW tetap ada.

    • Saya juga mengalami hal yang persis sama.
      Mengejutkan bahwa pada 2024, dengan semua fitur manajemen volume APFS yang pintar, sekadar memenuhi ruang penyimpanan pengguna saja bisa membuat perangkat “tertutup” seperti iPhone membutuhkan pemulihan DFU.
      Sebaliknya, ketika saya tanpa sengaja memenuhi ruang di laptop kerja Windows 11 yang memakai satu volume data/boot, perangkat masih bisa boot dan saya bisa membereskan masalahnya.

  • Belum lama ini saya mengalami situasi serupa di partisi sistem pada instalasi Linux.
    Sejak awal partisnya terlalu kecil, dan setelah update menumpuk, hampir tidak ada ruang tersisa bahkan untuk mulai menghapus sesuatu.
    Butuh sekitar 30 menit untuk menemukan subdirektori yang bisa dihapus meski hanya sedikit.
    Rasanya seperti terjebak di ruangan yang penuh barang rongsokan sampai pintu yang membuka ke dalam tidak bisa dibuka.
    Dari titik awal kecil itu, saya perlahan bisa menghapus ruang yang lebih besar, dan setelah akhirnya beres-beres, saya memperbesar ukuran partisi agar hal itu tidak terjadi lagi.

    • Saya penasaran kenapa sejak awal tidak memperluas partisinya.
      Pelajaran bagi pengguna berpengalaman sepertinya adalah selalu menyisakan sedikit ruang kosong di belakang partisi.