Ổ đĩa đầy đến mức không thể khôi phục

 (sixcolors.com)
2 điểm bởi GN⁺ 2024-04-05 | 1 bình luận | Chia sẻ qua WhatsApp
  • Ổ đĩa khởi động của một chiếc M2 MacBook Pro bị đầy đến mức chỉ còn 41KB trong lúc tải game trên Steam, khiến macOS rơi vào trạng thái thậm chí không thể xóa tệp
  • Tất cả các cách như dọn Thùng rác trong Finder, dùng rm và find -exec rm trong Terminal, cho đến xóa snapshot Time Machine trong Disk Utility đều thất bại với các lỗi kiểu “No space left on device”
  • Sau khi khởi động lại, máy cũng bị treo giữa chừng khi boot, và ngay cả khi mount qua recoveryOS và Share Disk trên Apple silicon sang một máy Mac khác cũng không thể ép xóa được
  • Đã thử khởi tạo lại ổ đĩa và cài lại macOS rồi khôi phục từ Time Machine, nhưng tiếp tục gặp các vấn đề như quá trình khôi phục trên Ventura bị dừng, chênh lệch phiên bản giữa Sonoma 14.4 và bản cũ 14.3.1, cùng lỗi mount mạng SMB/Samba
  • Cuối cùng, ảnh đĩa Time Machine mới nhất được sao chép sang SSD ngoài 1TB để khôi phục thủ công các tệp trong thư mục home và ứng dụng; khi cạn dung lượng lưu trữ và khôi phục bản sao lưu cùng thất bại, ngay cả người có kinh nghiệm cũng rất khó xử lý

Mac bị chặn cả thao tác xóa vì cạn dung lượng

  • Dung lượng lưu trữ của một chiếc M2 MacBook Pro đã đầy trong lúc tải một trò chơi mua hợp pháp trên Steam
  • macOS không dừng bản tải Steam dung lượng lớn dù ổ đĩa đã đầy đến mức nguy hiểm, và trên ổ khởi động chỉ còn lại 41KB
  • Phần lớn các tệp quan trọng nằm trên đám mây, và không có tình huống bắt buộc phải giữ lại các tệp lớn ở máy cục bộ
  • Vấn đề không chỉ là thiếu dung lượng đơn thuần, mà là hệ điều hành rơi vào trạng thái không thể xóa tệp bằng bất kỳ cách nào

Nguyên nhân bị nghi ngờ: tải xuống từ Steam và snapshot Time Machine cục bộ

  • Có khả năng macOS đã không kiểm soát được mức tăng dung lượng do kết nối Internet gigabit và các tệp lớn từ Steam
  • Đồng thời cũng có nghi ngờ rằng macOS đang tạo snapshot Time Machine cục bộ
  • macOS giữ các snapshot này để cung cấp bản sao lưu cục bộ trong 24 giờ gần nhất ngay cả khi đang sao lưu sang đích Time Machine là ổ ngoài hoặc qua mạng
  • Các tệp Steam nhìn bề ngoài giống như một tệp khổng lồ duy nhất, nhưng từ góc nhìn của Time Machine có thể đã bị xử lý khác đi
  • Có thể đã xảy ra xung đột giữa tệp thực tế trên máy và snapshot được tạo theo cách đặc biệt, nhưng nguyên nhân chính xác chưa được xác định

Mọi nỗ lực xóa đều thất bại

  • Dọn Thùng rác trong Finder thất bại từ File > Empty Trash
    • Thông báo lỗi là “The operation can’t be completed because the disk is full”
  • Terminal vẫn chạy được nhưng lệnh Unix tiêu chuẩn rm không hoạt động
    • Thông báo lỗi là “No space left on device”
    • Một cách thay thế dựa trên find để tìm tệp lớn rồi chạy rm bằng tùy chọn -exec cũng thất bại
  • Trong Disk Utility, việc chọn snapshot Time Machine trên ổ khởi động APFS để xóa cũng bị chặn bởi giới hạn tương tự
    • Thông thường, snapshot chỉ chiếm phần dung lượng cần cho khác biệt so với snapshot trước đó
    • Nhưng ngay cả trong trường hợp này vẫn xuất hiện lỗi “no space left”

Khởi động lại, recoveryOS và Share Disk cũng không giúp được

  • Máy được khởi động lại với hy vọng dọn bớt cache, nhưng sau đó không còn khởi động bình thường nữa
  • Thanh tiến trình lặp lại việc đi được khoảng nửa chừng rồi thất bại
  • Trong recoveryOS, khi ổ khởi động chưa được mount, đã thử sửa bằng Disk Utility và các thao tác liên quan đến cài lại hệ thống, nhưng các lệnh trong Terminal vẫn báo cùng lỗi
  • Đã thử dùng tính năng Share Disk trên Apple silicon để mount ổ này sang một máy Mac khác
    • Việc cố ép xóa thông qua chia sẻ ổ đĩa dựa trên Samba cũng thất bại

Sự cố tiếp diễn trong lúc khôi phục từ Time Machine

  • Có bản sao lưu Time Machine, bao gồm cả bản từ tối hôm trước, và phần lớn dữ liệu quan trọng đều ở trên đám mây nên không quá ám ảnh với việc phải khôi phục hoàn toàn
  • Trước tiên, ổ đĩa được xóa sạch và cài lại Ventura, là hệ thống mặc định đi kèm MacBook Pro khi xuất xưởng, thông qua macOS Recovery
  • Khi khởi động macOS, Migration Assistant được dùng để truy cập bản sao lưu Time Machine qua mạng, đồng thời bỏ chọn một số mục khôi phục để chừa đủ dung lượng trống
  • Giữa quá trình khôi phục, Ventura bị treo và sau đó không thể tiếp tục
  • Sau đó máy Mac được nâng cấp lên Sonoma, là phiên bản macOS đang dùng trước đó
    • Nâng cấp thành công nhưng phiên bản được cài là 14.4
    • Trên máy Mac cũ đang cài 14.3.1
    • Khi cố khôi phục trực tiếp ngay từ giai đoạn khởi động, thao tác này không được cho phép vì khác phiên bản

Vấn đề mount Time Machine qua mạng trên Sonoma 14.4

  • Một tài khoản người dùng mặc định trên Sonoma được tạo trước, rồi mới chạy Migration Assistant
  • Migration Assistant tìm thấy và nhận diện được máy Mac trên mạng đang quản lý bản sao lưu Time Machine
  • Tuy nhiên, nó không thể mount volume sao lưu của người con và liên tục hiện “Mount failed”
  • Kết quả tìm kiếm trên diễn đàn cho thấy quy trình mount mạng dựa trên SMB/Samba trong Sonoma bị lỗi đối với khôi phục Time Machine, và không tìm được cách khắc phục
  • Có vẻ như vấn đề này vẫn còn tồn tại trên macOS 14.4

Khôi phục cuối cùng: sao chép bản sao lưu sang SSD ngoài rồi chuyển thủ công

  • Cuối cùng phải từ bỏ việc khôi phục hoàn chỉnh bằng Migration Assistant và chỉ khôi phục thủ công các ứng dụng cùng tệp cần thiết
  • Trên máy Mac đang quản lý bản sao lưu mạng, ảnh đĩa của máy tính đó được mở bằng cách nhấp đúp rồi nhập mật khẩu của volume Time Machine
    • Với volume Time Machine qua mạng, luôn có một mật khẩu riêng được thiết lập từ trước
  • Biểu tượng đĩa có dấu thời gian mới nhất được tìm thấy và sao chép sang một SSD ngoài 1TB trống
  • SSD ngoài được gắn vào tài khoản tạm thời trên MacBook Pro để chuyển các tệp cần thiết
    • Nó chứa phần lớn nội dung trong các thư mục của home directory
    • Một số tệp tải xuống dung lượng lớn và video không cần thiết đã bị loại ra
  • SSD ngoài sẽ được giữ lại thêm một thời gian để có thể khôi phục bổ sung nếu phát hiện còn thiếu tệp

Những phương án thay thế chưa thể thử

  • Có thể đã unmount ổ Time Machine dùng cho sao lưu mạng khỏi máy Mac quản lý sao lưu rồi kết nối trực tiếp nó với máy Mac của người con
    • Trong trường hợp đó, có thể nó sẽ xuất hiện như điểm bắt đầu cho Migration Assistant
  • Cũng có thể sao chép đĩa ảo từ ảnh đĩa Time Machine đã mount để làm cho SSD ngoài 1TB trông giống như volume nguồn của máy Mac
    • Chưa xác nhận được cách này có thực sự hoạt động hay không
    • Nếu thành công, có thể đã khôi phục trực tiếp bằng Migration Assistant
  • Tuy nhiên, do đã mất nhiều giờ làm việc và hơn một ngày thử nghiệm, đồng thời người dùng cũng không quá cần việc khôi phục hoàn hảo ở cấp thư mục, nên không thử nghiệm thêm nữa

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-04-05
Ý kiến trên Hacker News

  • Có lẽ sẽ tốt hơn nếu tác giả khởi động Mac từ thiết bị lưu trữ ngoài, rồi xóa các tệp không cần thiết trên ổ đĩa trong: Use an external storage device as a Mac startup disk
    Điều gây ngạc nhiên là trên Mac dùng Apple Silicon, khi khởi động từ ổ ngoài thì không phải cổng nào cũng như nhau
    Khi cài macOS lên thiết bị lưu trữ, với laptop Mac cần tránh cổng USB-C ngoài cùng bên trái trong các cổng bên trái; còn iMac/Mac mini/Mac Studio/Mac Pro cũng có các cổng USB-C cần tránh tùy theo từng model
    Nghe nói sau khi cài xong thì cắm vào cổng nào cũng được

    • Về cơ bản tác giả đã thử điều tương tự như đề xuất rồi
      Tác giả đã khởi động vào recoveryOS, một phân vùng riêng, rồi cố xóa tệp trên phân vùng hệ thống chính, nhưng rm thất bại với cùng lỗi No space left on device
      Vì vậy, như những người khác đã nói, cách cắt ngắn tệp bằng echo -n >file có thể đã hoạt động
    • Nếu bản thân hệ thống tệp đã rơi vào deadlock, thì dù khởi động từ đâu, cách xóa tệp thông qua trình điều khiển hệ thống tệp cũng sẽ không hiệu quả
    • Ngay cả recoveryOS hay chế độ Mac Share Disk/Target Disk cũng không được, nên tôi tò mò vì sao lại cho rằng cách đó sẽ được
    • Những bình luận kiểu này chắc sẽ rất đáng mừng với ai đó 8 năm sau đang tìm kiếm để giải quyết vấn đề trên một chiếc Mac khi ấy đã cũ
    • Không biết có ai biết vì sao khi tạo OS có thể khởi động trên laptop Mac thì không nên dùng cổng USB-C đầu tiên không

  • Dựa trên chút hiểu biết về cấu trúc đĩa HFS+, tôi đoán tệp journal cũng đã đầy, mà việc xóa cần ghi vào journal và đôi khi cần mở rộng journal, nên có vẻ đã rơi vào trạng thái kỳ lạ trong đó bản thân thao tác xóa cũng tạm thời cần thêm dung lượng
    macOS đã tiếp tục ghi tệp cho đến khi ổ chỉ còn 41KB
    Tôi từng vô tình lấp đầy NTFS và FAT32 đến 0 byte, nhưng khi đó vẫn có thể xóa thứ gì đó
    Lục các diễn đàn thì thấy Sonoma đã làm hỏng quy trình mount mạng dựa trên SMB/Samba để khôi phục Time Machine, và có vẻ đến 14.4 vẫn chưa có cách giải quyết
    Theo kinh nghiệm của tôi, SMB đã trở nên khó tin cậy và quá nhiều lỗi từ khoảng 10.12~10.13, và giờ có vẻ Apple thậm chí chẳng còn quan tâm liệu nó có hoạt động hay không
    Tôi không muốn tưởng tượng những người không có hàng chục năm kinh nghiệm với Mac sẽ làm gì khi gặp kiểu hỏng hóc dây chuyền của hệ thống như thế này
    Tôi không có hàng chục năm kinh nghiệm với Mac, nhưng trong tình huống này tôi sẽ thử fsck trước, nên thấy lạ là ở đây không nhắc đến
    Nếu không thể sao chép nội dung đĩa sang đĩa khác rồi định dạng và chép trả lại, có lẽ tôi sẽ xem tài liệu APFS (https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf) rồi dùng dd và trình sửa hex để tìm xem cần sửa chỗ nào nhằm tạo ra dung lượng trống

    • Đó là theo hệ thống tệp có journaling; còn với hệ thống tệp copy-on-write (CoW), mọi thay đổi được thực hiện bằng cách tạo một cây tệp mới rồi cho root trỏ đến cây mới đó
      Sau đó garbage collection tìm các tệp không còn thuộc cây đang hoạt động và trả lại chúng làm không gian lưu trữ
      Thông thường các thay đổi được gom lại để giữ lượng thay đổi của cây ở mức có thể xử lý, và nhờ thiết kế này, snapshot hệ thống tệp trở thành một tham chiếu khác đến một cây cụ thể
      Quá trình này cần dung lượng, nhưng các hệ thống tệp CoW thường dành riêng một vùng lưu trữ khẩn cấp vì lý do đó
    • Apple đã chuyển sang triển khai riêng từ lâu sau khi Samba áp dụng 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
    • Đúng kiểu Apple, hiệu năng SMB vài năm trước chậm đến kinh khủng, và gần đây cũng chỉ vừa tạm chấp nhận được, chậm hơn nhiều so với NFS trên cùng phần cứng hoặc, trớ trêu thay, Appleshare
      Vài năm trước, khi đo bằng BlackMagic Disk Speed Test trên một Hackintosh kết nối với NAS lớn qua 10GbE, SMB trên Windows đạt 900MB/s, SMB trên macOS đạt 200MB/s, còn NFS và AFP trên macOS đều đạt 1000MB/s
      Những tính năng macOS liên quan đến công việc chuyên nghiệp, đáng tiếc là ở mức nực cười
      Người ta nói AFP đã chết, nhưng trên Mac Pro của tôi nó vẫn hoạt động tốt với vai trò client, và hiệu năng tốt hơn SMB đến mức gần như hài hước
    • Nếu tự mình gặp phải thì không vui, nhưng BTRFS và ZFS cũng có thể xảy ra chuyện tương tự
      Nếu lấp đầy đến tận cùng thì có thể phát sinh vấn đề
      BTRFS cố chuyển sang chế độ chỉ đọc khi vẫn còn dung lượng metadata, để có thể mount lại ở chế độ an toàn và xóa thứ gì đó, nhưng không có cơ chế bảo vệ nào hoàn hảo
      Theo tôi biết thì NTFS và FAT32 không phải là hệ thống tệp có journaling
    • Cho đến giờ, đây có vẻ là lời giải thích kỹ thuật đúng đắn duy nhất

  • Tôi từng gặp chuyện này ở công việc đầu tiên
    Tôi vô tình làm đầy cluster bằng các file rác, rồi quản trị viên hệ thống bắt đầu gửi email giục sửa nhanh, nhưng rm lại không hoạt động
    Khi đó tôi học được rằng ngay cả khi không xóa được, việc cắt ngắn file thường vẫn làm được, nên khi rm foo không chạy thì dùng cat /dev/null > foo thường sẽ hiệu quả

    • Trong shell, :>filepath thường dùng được
      Tuy nhiên một số filesystem có thể cũng không làm được việc đó
      Trong trường hợp như vậy, bạn phải hy vọng filesystem hỗ trợ mở rộng kích thước, thu nhỏ kích thước, tạm thời thêm dung lượng lưu trữ, hoặc hệ thống bên dưới có thể thêm/gỡ backing storage
      Cũng có thể cần một lệnh riêng để đưa cấu trúc trở lại dạng dành cho một block device đơn lẻ, như btrfs
    • Vài năm trước, có một tình huống trong đó hạ tầng cốt lõi, vốn luôn phải ghi được vào filesystem, có thể bị kẹt cứng không thể phục hồi
      Vì vậy chúng tôi cho tiến trình backup định kỳ gửi thẳng dữ liệu rác vào /dev/null, và có lẽ bản hack bẩn thỉu đó đến giờ vẫn còn chạy
      /dev/null giống như phép màu, đáng để đọc qua một lần
    • Thực ra chỉ cần >file cũng được
    • Tuy nhiên như nhiều bình luận ở đây, cũng có những tình huống mà ngay cả cắt ngắn cũng thất bại
      Các định dạng filesystem thế kỷ 21 phức tạp hơn UFS rất nhiều, và những tính năng như snapshot và journaling tạo ra các cách mới để filesystem tự rơi vào deadlock
    • Tôi từng để mức log của Samba quá cao để debug rồi quên hạ xuống, khiến SSD root ZFS bị lấp đầy bởi một file log khổng lồ
      Cuối cùng phải phục hồi bằng truncate
      Tôi biết ZFS tốt hơn trong những tình huống như vậy, nhưng cảm giác chìm xuống kiểu “ôi… chết tiệt” khi nhận ra mình thật sự làm hỏng chuyện thì vẫn y như vậy

  • Time Machine có vẻ ngày càng tệ đi
    Tôi không hiểu vì sao lại không có động lực để làm cho nó ổn định và hoạt động đúng
    Sau khi gặp các chuyện như sparse bundle bị hỏng phải bắt đầu backup mới, hoặc tính năng bị lỗi, giờ tôi cảm thấy Time Machine không còn đáng để thiết lập cho lắm
    Hoàn toàn trái ngược với backup iOS/iPadOS, vốn lần nào cũng hoạt động tốt

    • Vì họ không còn bán Time Capsule nữa
      Apple muốn mọi người backup mọi thứ lên iCloud để tăng doanh thu dịch vụ
    • Nhìn từ góc độ một người không dùng Mac, chuyện này nghe như một lỗi thảm họa và không thể biện minh, kiểu sẽ bị chỉ trích dữ dội nếu đó là hệ điều hành desktop có linh vật chim cánh cụt hoặc có trụ sở ở Washington
    • Số lần Time Machine đột nhiên quyết định không muốn làm việc nữa, khiến tôi phải xóa backup và bắt đầu lại, là quá nhiều
    • Quản lý chất lượng của macOS đã đi xuống kể từ khi Scott Forstall bị sa thải, và thật ra ngay cả thời ông ấy còn ở đó cũng không đến mức đáng kinh ngạc
    • Trải nghiệm của tôi thì khác
      Tôi đã chạy Time Machine trên share Samba cho nhiều máy Mac suốt vài năm nay, và chỉ thấy nó cải thiện
      Trước đây, sparse bundle của Time Machine hay bị hỏng, phải tạo mới hoặc khôi phục snapshot ZFS cũ để tiếp tục
      Khi đó hình như là AFP chứ không phải SMB
      Gần đây tôi không gặp vấn đề này trên bất kỳ thiết bị nào, dù tôi có bật một số flag cụ thể được khuyến nghị cho backup Time Machine trong smb.conf

  • Ngược lại, ZFS có slop space để tránh việc filesystem bị khựng lại khi hết dung lượng giữa một tác vụ lớn
    Theo mặc định, nó dự trữ 3,2% dung lượng volume, tối đa 128GB
    Vì vậy nếu thay đổi giá trị tinh chỉnh kernel Linux spa_slop_shift để giảm slop space, bạn có thể lấy lại tối đa 128GB dung lượng bonus nhằm hoàn tất thành công thao tác xóa file: https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#spa-slop-shift

    • Đúng vậy
      Vì lý do này, tính năng dự trữ một tỷ lệ nhất định dung lượng đĩa đã là chức năng phổ biến của các filesystem “thực thụ” từ nhiều thập kỷ trước khi ZFS hay Linux tồn tại
      Nó giống việc hầu hết chương trình terminal shareware trên MS-DOS thập niên 1980 tải file qua kết nối băng thông hạn chế rất tốt, trong khi MS Windows hiện nay lại làm rất tệ một việc đáng ra phải nhỏ nhặt như vậy
    • ext4 cũng có tính năng tương tự, chỉ là gọi là reserved blocks
      Xem man tune2fs để biết chi tiết
      Hầu hết các filesystem hiện đại, hoặc không hiện đại lắm, khác cũng vậy
      Theo tôi nhớ thì UFS trên SunOS thập niên 1980 cũng như thế: https://en.wikipedia.org/wiki/SunOS

  • Mọi người khó hiểu khái niệm rằng để xóa một thứ gì đó, thực tế có thể cần thêm dung lượng, dù là tạm thời hay vĩnh viễn
    Các bình luận khác đã nói kỹ vì sao các filesystem hiện đại như snapshot, journaling phải cấp phát từ dung lượng trống để thực hiện xóa
    Trong các lĩnh vực khác cũng tương tự: trong 10 năm đầu của Wikipedia, người ta thường phải giải thích rằng cố xóa trang để tiết kiệm dung lượng máy chủ thực ra lại có tác dụng ngược
    Vì ít nhất là từ khoảng năm 2004 trở đi, thao tác xóa sẽ thêm một record vào database nội bộ
    Trong định dạng archive ZOO của Rahul Dhesi, xóa mục chỉ là đặt một flag trong header record, và còn có kiểu quản lý phiên bản file theo phong cách VMS, trong đó thêm phiên bản mới cũng không ghi đè phiên bản cũ
    Thời MS/DR/PC-DOS và FAT, nếu có cài tiện ích phục hồi xóa, khi xóa file có thể cần thêm dung lượng để lưu một mục mới vào database chứa thông tin phục hồi
    Một số tiện ích nén đĩa cũ còn nén cả metadata, nên trong những tình huống hiếm gặp, thay đổi metadata có thể làm thay đổi tỷ lệ nén và thực sự làm tăng kích thước volume nhìn thấy từ bên ngoài
    Ý tưởng xóa để giải phóng dung lượng rất phổ biến, nhưng nói một cách nghiêm ngặt thì không phải lúc nào cũng đúng

  • Tôi từng gặp vấn đề tương tự vào tháng 10/2018 và đã để lại trong câu hỏi Stack Overflow dưới đây
    May mắn là tôi có thêm một phân vùng APFS có thể xóa được, nhờ đó giải phóng được dung lượng đĩa
    Mất khá nhiều thời gian mới phát hiện ra điều đó, và trong lúc ấy tôi đã thực sự hoảng loạn
    https://apple.stackexchange.com/questions/338721/disk-full-terminal-in-recovery-mode-won-t-delete-files-boot-kernel-panics
    Ngay sau khi cập nhật macOS Mojave, tôi đang tạo một file .dmg thì làm đầy đĩa và hệ thống bị treo
    Khởi động lại thì gặp kernel panic; tôi boot vào chế độ khôi phục, mount đĩa rồi chạy rm /path/to/large/file trong terminal, nhưng nhận được lỗi No space left on device
    Về bản chất, đây là cùng vấn đề với luồng Unix từ năm 2008: https://www.unix.com/linux/69889-unable-remove-file-using-rm-disk-space-full.html
    echo x > /path/to/large/file cũng không có tác dụng, và tôi cần một đề xuất khác ngoài “xóa ổ đĩa rồi khôi phục từ bản sao lưu”

    • Tạo sẵn một phân vùng bổ sung nhỏ khoảng 1GB có thể là một dạng bảo hiểm tốt
      Tương tự việc các hệ thống file Unix ngày xưa dành riêng 5% cho root
    • Trong bài StackExchange đó, về sau cũng có thêm các giải pháp tiềm năng khác
      Nếu xóa phân vùng bộ nhớ ảo, với điều kiện nó đủ lớn, có thể lấy lại đủ dung lượng để xóa file
    • Với APFS thì chuyện đó không đơn giản như vậy
      Vì container chỉ được cấp phát khi thực sự được dùng

  • Ấn tượng thật
    Tôi chưa từng gặp tình huống đến cả rm cũng thất bại, nhưng đã trải qua sự khó chịu khi dùng và quản lý các máy Mac hiện đại có bộ nhớ trong từ 256GB trở xuống
    Vì vậy tôi thường tạo sẵn một file giữ chỗ khoảng 16GB
    Dù sao nếu dung lượng đầy đến mức chặn cập nhật hoặc việc khác, chỉ cần xóa file đó là được, khỏi phải dọn dẹp kiểu phẫu thuật bằng ncdu

    • Tôi cũng thấy CockroachDB làm điều tương tự khi khởi động node: https://www.cockroachlabs.com/docs/v23.2/cluster-setup-troubleshooting#automatic-ballast-files
    • Ưu điểm lớn của file giữ chỗ là khi cần, bạn có thể giải phóng phần dung lượng đó để có thời gian thực hiện giải pháp dài hạn
      Chẳng hạn như dùng chi phí một giờ của nhân viên hoặc thiết bị để mua ổ mới lớn gấp bốn lần ổ cũ

  • Tôi cũng từng gặp chuyện tương tự trên iPhone
    Đĩa đầy đến mức dù xóa thứ gì đó, thực tế trông như chẳng có gì xảy ra
    Khởi động lại thì không đăng nhập được, khởi động lại lần nữa thì rơi vào boot loop
    Khởi động lại thêm một lần, máy boot vào trạng thái không nhất quán: trên màn hình chính vẫn còn biểu tượng ứng dụng, nhưng ứng dụng thực tế đã biến mất, biểu tượng rỗng và không chạy được
    Lo ngại về tính toàn vẹn dữ liệu, cuối cùng tôi đã khôi phục từ bản sao lưu
    Tôi tin chắc đây là hệ quả của việc APFS dùng cơ chế copy-on-write và hỗ trợ snapshot
    Nếu các thay đổi không được ghi bền vững ngay lập tức và phiên bản cũ của file vẫn nằm trong snapshot, thì sẽ rắc rối khi đến cả dung lượng cho metadata của snapshot cũng không còn
    Khi thiếu dung lượng đĩa, có thể bỏ qua snapshot, nhưng vấn đề metadata CoW vẫn còn

    • Tôi cũng gặp đúng chuyện như vậy
      Thật đáng ngạc nhiên là đến năm 2024, dù có đủ các tính năng quản lý volume APFS thông minh, chỉ cần lấp đầy bộ nhớ người dùng cũng có thể khiến một thiết bị “đóng kín” như iPhone rơi vào trạng thái cần khôi phục DFU
      Ngược lại, khi tôi vô tình làm đầy dung lượng trên laptop công việc chạy Windows 11 dùng chung một volume dữ liệu/boot, máy vẫn có thể boot để tôi dọn dẹp vấn đề

  • Cách đây không lâu, tôi cũng gặp tình huống tương tự trên phân vùng hệ thống của một bản cài Linux
    Ngay từ đầu phân vùng đã quá nhỏ, và khi các bản cập nhật tích tụ, gần như không còn chỗ để bắt đầu xóa bất cứ thứ gì
    Tôi mất khoảng 30 phút để tìm một thư mục con có thể xóa được dù chỉ một chút
    Cảm giác như bị kẹt trong một căn phòng chất đầy đồ linh tinh đến mức không thể mở cánh cửa mở vào trong
    Từ điểm khởi đầu nhỏ đó, tôi dần xóa được các phần dung lượng lớn hơn, và sau khi cuối cùng dọn xong, tôi đã tăng kích thước phân vùng để không bao giờ gặp lại chuyện đó nữa

    • Tôi tò mò vì sao ngay từ đầu bạn không mở rộng phân vùng
      Có lẽ bài học cho người dùng thành thạo là luôn chừa lại một ít dung lượng trống phía sau phân vùng