복원할 수 없을 정도로 가득 찬 디스크

 (sixcolors.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • M2 MacBook Pro의 시동 볼륨이 Steam 게임 다운로드 중 41KB만 남을 정도로 가득 차며, macOS가 파일 삭제조차 못 하는 상태에 빠짐
  • Finder 휴지통 비우기, Terminal의 rm과 find -exec rm, Disk Utility의 Time Machine 스냅샷 삭제까지 모두 “No space left on device” 계열 오류로 실패함
  • 재시동 뒤에는 부팅도 중간에서 멈췄고, recoveryOS와 Apple silicon의 Share Disk로 다른 Mac에 마운트해도 삭제를 강제하지 못함
  • 드라이브 초기화와 macOS 재설치 후 Time Machine 복원을 시도했지만, Ventura 복원 중단, Sonoma 14.4와 기존 14.3.1의 버전 차이, SMB/Samba 네트워크 마운트 실패가 이어짐
  • 결국 최신 Time Machine 디스크 이미지를 외장 1TB SSD로 복사해 홈 디렉터리 파일과 앱을 수동 복구했으며, 저장공간 고갈과 백업 복원 실패가 겹치면 숙련자도 대응하기 어려움

저장공간 고갈로 삭제도 막힌 Mac

  • M2 MacBook Pro의 저장공간이 Steam에서 합법적으로 구매한 게임을 다운로드하는 동안 가득 참
  • macOS는 드라이브가 위험하게 찼는데도 대용량 Steam 다운로드를 멈추지 않았고, 시동 볼륨에는 41KB만 남음
  • 대부분의 중요한 파일은 클라우드에 있었고, 로컬의 큰 파일을 반드시 보존해야 하는 상황은 아니었음
  • 문제는 단순한 용량 부족이 아니라, 운영체제가 어떤 방식으로도 파일을 지우지 못하는 상태였음

의심된 원인: Steam 다운로드와 로컬 Time Machine 스냅샷

  • 기가비트 인터넷 연결과 큰 Steam 파일 때문에 macOS가 저장공간 증가를 제어하지 못했을 가능성이 있음
  • 동시에 macOS가 로컬 Time Machine 스냅샷을 만들고 있었던 점이 의심됨
  • macOS는 외장 또는 네트워크 Time Machine 대상에 백업하는 중에도 최근 24시간의 로컬 백업을 제공하기 위해 스냅샷을 유지함
  • Steam 파일은 겉으로는 하나의 거대한 파일처럼 보였지만, Time Machine 관점에서는 다르게 처리됐을 가능성이 있음
  • 로컬의 실제 파일과 특수하게 생성된 스냅샷이 충돌했을 수 있으나, 정확한 원인은 확정되지 않음

모두 실패한 삭제 시도

  • Finder 휴지통 비우기는 File > Empty Trash에서 실패함
    • 오류 메시지는 “The operation can’t be completed because the disk is full”이었음
  • Terminal은 실행됐지만 표준 Unix rm 명령이 동작하지 않음
    • 오류 메시지는 “No space left on device”였음
    • 큰 파일을 찾은 뒤 -exec 옵션으로 rm을 실행하는 find 기반 대안도 실패함
  • Disk Utility에서도 APFS 시동 볼륨의 Time Machine 스냅샷을 선택해 삭제하려 했지만 같은 한계에 막힘
    • 일반적으로 스냅샷은 이전 스냅샷과의 차이에 필요한 저장공간만 차지함
    • 이 경우에도 “no space left” 오류가 발생함

재시동, recoveryOS, Share Disk도 통하지 않음

  • 캐시 정리를 기대하고 재시동했지만, Mac은 더 이상 정상 부팅되지 않음
  • 진행 막대가 절반 정도까지 간 뒤 실패하는 상태가 반복됨
  • recoveryOS에서 시동 볼륨이 마운트되지 않은 상태로 Disk Utility 수리와 재설치 관련 작업을 시도했지만, Terminal 명령은 같은 오류를 냄
  • Apple silicon의 Share Disk 기능으로 해당 드라이브를 다른 Mac에 마운트하려 함
    • Samba 기반 디스크 공유를 통해 삭제를 강제하려 했지만 실패함

Time Machine 복원 중 이어진 장애

  • 이전 저녁 백업을 포함한 Time Machine 백업이 있었고, 중요한 데이터 대부분은 클라우드에 있어 완전 복구에 크게 집착하지 않는 상황이었음
  • 먼저 드라이브를 지우고 macOS Recovery로 MacBook Pro 출고 당시 기본 시스템인 Ventura를 재설치함
  • macOS 시작 시 Migration Assistant로 네트워크 Time Machine 백업에 접근하고, 충분한 저장공간을 남기기 위해 일부 복원 항목을 해제함
  • 복원 도중 Ventura가 중간에서 멈췄고 이후 재개되지 않음
  • 이후 Mac을 당시 사용 중이던 macOS인 Sonoma로 업그레이드함
    • 업그레이드는 성공했지만 설치된 버전은 14.4였음
    • 기존 Mac에는 14.3.1이 설치돼 있었음
    • 시작 단계에서 직접 복원하려 하자 버전 차이 때문에 허용되지 않음

Sonoma 14.4의 네트워크 Time Machine 마운트 문제

  • 기본 Sonoma 사용자 계정을 만든 뒤 Migration Assistant를 실행함
  • Migration Assistant는 Time Machine 백업을 관리하는 네트워크 Mac을 찾고 인식함
  • 그러나 자녀의 백업 볼륨을 마운트하지 못했고, 반복해서 “Mount failed”가 표시됨
  • 포럼 검색 결과, Sonoma에서 SMB/Samba 기반 네트워크 마운트 절차가 Time Machine 복원에 깨져 있으며 해결책을 찾지 못한 상태였음
  • 이 문제는 macOS 14.4에서도 여전히 해당되는 것으로 보였음

최종 복구: 백업을 외장 SSD로 복사해 수동 이전

  • 완전한 Migration Assistant 복원을 포기하고, 필요한 앱과 파일만 수동으로 복구함
  • 네트워크 백업을 관리하는 Mac에서 해당 컴퓨터의 디스크 이미지를 더블클릭하고 Time Machine 볼륨 암호를 입력함
    • 네트워크 Time Machine 볼륨에는 항상 별도 암호를 설정해 둔 상태였음
  • 최신 타임스탬프가 붙은 디스크 아이콘을 찾아 빈 외장 1TB SSD로 복사함
  • 외장 SSD를 MacBook Pro의 임시 계정에 연결해 필요한 파일을 옮김
    • 홈 디렉터리 폴더 대부분의 내용이 포함됨
    • 큰 다운로드 파일과 필요 없는 비디오 파일 일부는 제외됨
  • 외장 SSD는 누락 파일이 있을 때 추가 복구할 수 있도록 당분간 보관하기로 함

시도하지 못한 대안

  • 네트워크 백업용 Time Machine 드라이브를 백업 관리 Mac에서 언마운트한 뒤 자녀의 Mac에 직접 연결할 수 있었음
    • 이 경우 Migration Assistant의 시작점으로 나타났을 가능성이 있음
  • 마운트한 Time Machine 디스크 이미지에서 가상 디스크를 복사해 외장 1TB SSD가 Mac 소스 볼륨처럼 보이게 만들 수도 있었음
    • 이 방식이 실제로 작동했을지는 확인되지 않음
    • 성공했다면 Migration Assistant로 직접 복원할 가능성이 있었음
  • 이미 몇 시간의 작업과 하루 이상의 시도가 누적됐고, 사용자가 완벽한 디렉터리 단위 복구를 크게 원하지 않아 추가 실험은 하지 않음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 글쓴이는 외장 저장장치로 Mac을 부팅한 뒤 내부 디스크에서 불필요한 파일을 지웠다면 더 나았을 수도 있음: Use an external storage device as a Mac startup disk
    Apple Silicon 기반 Mac에서는 외장 부팅 시 모든 포트가 동등하지 않다는 점이 의외였음
    macOS를 저장장치에 설치할 때 Mac 노트북은 왼쪽 포트 중 가장 왼쪽 USB-C 포트를 피해야 하고, iMac/Mac mini/Mac Studio/Mac Pro도 모델별로 피해야 하는 USB-C 포트가 따로 있음
    설치가 끝난 뒤에는 어느 포트에 연결해도 된다고 함

    • 제안한 것과 사실상 같은 시도를 이미 했음
      글쓴이는 별도 파티션인 recoveryOS로 부팅한 뒤 메인 시스템 파티션에서 파일을 지우려 했지만, rm이 같은 No space left on device 오류로 실패했음
      그래서 다른 사람들이 말한 것처럼 echo -n >file로 파일을 잘라내는 방식은 동작했을 수도 있음
    • 파일시스템 자체가 교착 상태에 빠졌다면, 어디서 부팅하든 파일시스템 드라이버를 통해 파일을 지우는 방식은 통하지 않음
    • recoveryOS나 Mac Share Disk/Target Disk 모드로도 안 됐는데, 왜 그 방식은 될 거라고 보는지 궁금함
    • 이런 댓글은 8년 뒤 당시엔 낡은 Mac 문제를 해결하려고 검색하는 누군가에게 정말 반가울 것 같음
    • Mac 노트북에서 부팅 가능한 OS를 만들 때 왜 첫 번째 USB-C 포트를 쓰면 안 되는지 아는 사람이 있는지 궁금함

  • HFS+ 디스크 구조에 대한 약간의 지식으로 추측해 보면, 저널 파일도 가득 찼고 삭제에는 저널에 쓰기와 경우에 따라 확장이 필요하니, 삭제 자체가 일시적으로라도 더 많은 공간을 요구하는 이상한 상태가 된 듯함
    macOS는 드라이브에 41KB만 남을 때까지 계속 파일을 썼음
    NTFS와 FAT32를 실수로 0바이트까지 채운 적이 있는데, 그때도 무언가를 삭제하는 건 가능했음
    포럼을 뒤져 보니 Sonoma가 Time Machine 복원용 SMB/Samba 기반 네트워크 마운트 절차를 망가뜨렸고, 14.4에서도 해결책이 아직 없는 듯함
    경험상 SMB는 10.12~10.13 무렵부터 신뢰하기 어렵고 버그가 너무 많아졌으며, 이제 Apple은 이게 동작하는지조차 신경 쓰지 않는 것처럼 보임
    수십 년 Mac 경험이 없는 사람들은 이런 연쇄적인 시스템 실패를 만나면 어떻게 할지 상상하기 싫음
    수십 년 Mac 경험은 없지만, 이런 상황이면 먼저 fsck를 시도했을 텐데 여기서 언급이 안 된 게 이상함
    디스크 내용을 다른 디스크로 복사한 뒤 포맷하고 되돌릴 수 없다면 APFS 문서(https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf)를 보고 dd와 16진수 편집기로 어디를 고쳐야 여유 공간을 만들 수 있을지 찾아볼 것 같음

    • 그건 저널링 파일시스템 기준이고, 기록 시 복사(CoW) 파일시스템에서는 모든 변경이 새 파일 트리를 만든 뒤 루트가 그 새 트리를 가리키게 하는 방식으로 이뤄짐
      이후 가비지 컬렉션이 활성 트리에 더 이상 속하지 않는 파일을 찾아 저장공간으로 되돌림
      보통 트리 변경량을 감당 가능한 수준으로 줄이기 위해 변경을 묶어서 처리하고, 이 설계 덕분에 파일시스템 스냅샷은 특정 트리에 대한 또 다른 참조가 됨
      이 과정에는 공간이 필요하지만, CoW 파일시스템은 보통 이런 이유로 긴급 저장공간을 따로 예약해 둠
    • Apple은 Samba가 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
    • Apple답게 SMB 성능은 몇 년 전엔 끔찍하게 느렸고, 최근에도 겨우 봐줄 만한 수준일 뿐 같은 하드웨어의 NFS나, 아이러니하게도 Appleshare보다 훨씬 느림
      몇 년 전 10GbE로 큰 NAS에 연결한 Hackintosh에서 BlackMagic Disk Speed Test로 측정했을 때 Windows의 SMB는 900MB/s, macOS의 SMB는 200MB/s, macOS의 NFS와 AFP는 둘 다 1000MB/s가 나왔음
      전문 작업과 관련된 macOS 기능은 안타깝게도 우스운 수준임
      AFP가 죽었다고들 하지만 내 Mac Pro에서는 클라이언트로 여전히 잘 동작하고, SMB보다 성능이 너무 좋아 거의 코미디처럼 느껴짐
    • 직접 당하면 재미없지만, BTRFS와 ZFS에서도 같은 일이 가능함
      끝까지 가득 채우면 문제가 생길 수 있음
      BTRFS는 메타데이터 공간이 아직 남아 있을 때 읽기 전용으로 전환하려고 해서 안전 모드로 다시 마운트하고 무언가를 지울 수 있게 하지만, 완벽한 보호장치는 없음
      NTFS와 FAT32는 내가 알기로 저널링 파일시스템이 아닌 것으로 알고 있음
    • 지금까지는 이게 유일하게 제대로 된 기술적 설명처럼 보임

  • 첫 직장에서 이런 일을 겪었음
    실수로 클러스터를 잡파일로 가득 채웠고, 시스템 관리자가 빨리 고치라고 이메일을 보내기 시작했는데 rm이 동작하지 않았음
    그때 삭제가 안 될 때도 파일 잘라내기는 보통 된다고 배웠고, 그래서 rm foo가 안 될 때 cat /dev/null > foo를 쓰면 되는 경우가 많음

    • 셸에서는 :>filepath가 자주 통함
      다만 어떤 파일시스템은 그것도 못 할 수 있음
      그런 경우 파일시스템이 크기 확장, 크기 축소, 임시 추가 저장공간을 지원하거나, 하위 시스템에서 백킹 저장소를 추가/제거할 수 있기를 바라야 함
      btrfs처럼 단일 블록 장치용 구조로 되돌리기 위해 별도 명령이 필요할 수도 있음
    • 몇 년 전, 항상 파일시스템에 쓸 수 있어야만 하는 핵심 인프라가 교착 상태로 복구 불가능하게 망가질 수 있는 상황이 있었음
      그래서 백업 프로세스가 주기적으로 쓰레기 데이터를 /dev/null로 직접 보내게 했고, 아마 그 지저분한 해킹은 아직도 돌아가고 있을 것임
      /dev/null은 마법 같아서 한 번 읽어볼 가치가 있음
    • 사실 그냥 >file만 해도 됨
    • 다만 여기 여러 댓글처럼 잘라내기조차 실패하는 상황도 있음
      21세기 파일시스템 형식은 UFS보다 훨씬 복잡하고, 스냅샷과 저널링 같은 기능 때문에 파일시스템이 스스로 교착 상태에 빠지는 새로운 방식들이 생김
    • Samba 로그 수준을 디버깅 때문에 너무 높여 놓고 되돌리는 걸 잊어서, 거대한 로그 파일로 ZFS 루트 SSD를 가득 채운 적이 있음
      결국 truncate로 복구해야 했음
      ZFS가 이런 상황에 더 낫다는 건 알고 있었지만, 그래도 진짜 망쳤다는 느낌이 들 때의 “아… 젠장” 하는 침몰감은 그대로였음

  • Time Machine은 꾸준히 나빠지는 것 같음
    왜 안정적이고 제대로 동작하게 만들 동기가 없는지 모르겠음
    sparse bundle이 손상돼 새 백업을 시작해야 하거나 기능이 실패하는 일을 겪다 보니, 이제는 Time Machine을 설정할 가치가 별로 없다고 느낌
    매번 잘 동작했던 iOS/iPadOS 백업과는 완전히 대조적임

    • 더 이상 Time Capsule을 팔지 않기 때문임
      Apple은 사람들이 모든 걸 iCloud에 백업해서 서비스 매출을 키우길 원함
    • Mac을 쓰지 않는 입장에서 보면, 이건 펭귄 마스코트가 있거나 본사가 워싱턴에 있는 데스크톱 운영체제였다면 엄청난 비난을 불렀을 재앙적이고 변명 불가능한 버그처럼 들림
    • Time Machine이 갑자기 더 이상 일하기 싫다고 결정해서 백업을 지우고 새로 시작해야 했던 횟수가 너무 많음
    • macOS 품질 관리는 Scott Forstall을 해고한 뒤로 하락해 왔고, 사실 그가 있던 시절에도 놀라운 수준은 아니었음
    • 내 경험은 다름
      여러 Mac에서 Samba 공유 위에 Time Machine을 몇 년째 돌리고 있는데 오히려 개선만 봤음
      예전에는 Time Machine sparse bundle이 자주 손상돼 새로 만들거나, 이전 ZFS 스냅샷을 복원해서 이어가야 했음
      그때는 SMB가 아니라 AFP였던 것 같음
      최근에는 어떤 기기에서도 이런 문제가 없었고, Time Machine 백업용으로 권장되는 특정 플래그들을 smb.conf에 켜 두긴 했음

  • 반대로 ZFS에는 큰 작업 중 공간이 바닥나 파일시스템이 멈추는 일을 피하기 위한 slop space가 있음
    기본값으로 볼륨 공간의 3.2%를 최대 128GB까지 예약함
    그래서 Linux 커널 조정값인 spa_slop_shift를 바꿔 slop space를 줄이면, 파일 삭제 작업을 성공적으로 끝내기 위한 보너스 공간을 최대 128GB까지 되찾을 수 있음: https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#spa-slop-shift

    • 맞음
      이런 이유로 디스크 공간의 일정 비율을 예약하는 기능은 ZFS나 Linux가 존재하기 수십 년 전부터 “진짜” 파일시스템의 흔한 기능이었음
      1980년대 MS-DOS 셰어웨어 터미널 프로그램 대부분은 제한된 대역폭 연결에서 파일 다운로드를 아주 잘했는데, 현재 MS Windows는 그런 사소해야 할 작업도 형편없는 것과 비슷함
    • ext4도 같은 기능이 있고, 다만 이름을 reserved blocks라고 부름
      자세한 건 man tune2fs를 보면 됨
      현대적이거나 그다지 현대적이지 않은 대부분의 다른 파일시스템도 마찬가지임
      기억으로는 1980년대 SunOS의 UFS도 그랬음: https://en.wikipedia.org/wiki/SunOS

  • 무언가를 삭제하는 데 실제로 더 많은 공간이 일시적이든 영구적이든 필요할 수 있다는 개념을 사람들이 이해하기 어려워함
    다른 댓글들이 스냅샷, 저널링 같은 현대 파일시스템이 삭제를 위해 여유 공간에서 할당해야 하는 이유를 자세히 다뤘음
    다른 분야에서도 비슷하게, Wikipedia 초기 10년 동안에는 페이지를 지워 서버 공간을 아끼려는 시도가 실제로는 반대 효과를 낸다고 자주 설명해야 했음
    적어도 2004년 무렵 이후 삭제는 내부 데이터베이스에 레코드를 추가했기 때문임
    Rahul Dhesi의 ZOO 아카이브 형식에서는 항목 삭제가 헤더 레코드에 플래그를 세우는 것뿐이었고, 새 버전을 추가해도 이전 버전을 덮어쓰지 않는 VMS식 파일 버전 관리도 있었음
    MS/DR/PC-DOS와 FAT 시절에는 삭제 복구 유틸리티가 설치돼 있으면, 파일 삭제 시 복구 정보를 담은 데이터베이스에 새 항목을 저장하느라 더 많은 공간이 필요할 수 있었음
    일부 오래된 디스크 압축 유틸리티는 메타데이터까지 압축했기 때문에, 메타데이터 변경이 압축률을 바꿔 외부에서 보이는 볼륨 크기를 실제로 늘리는 드문 상황도 가능했음
    삭제해서 공간을 확보한다는 생각은 널리 퍼져 있지만, 엄밀히 항상 맞는 말은 아님

  • 2018년 10월에 같은 문제를 겪었고, 아래 Stack Overflow 질문에 남겨 뒀음
    운 좋게도 제거할 수 있는 추가 APFS 파티션이 있어서 디스크 공간을 확보할 수 있었음
    그걸 알아내기까지 시간이 꽤 걸렸고, 그동안 제대로 패닉 상태였음
    https://apple.stackexchange.com/questions/338721/disk-full-terminal-in-recovery-mode-won-t-delete-files-boot-kernel-panics
    macOS Mojave를 막 업데이트한 뒤 .dmg를 만들다가 디스크를 가득 채웠고 시스템이 멈췄음
    재부팅하니 커널 패닉이 났고, 복구 모드로 부팅해 디스크를 마운트한 뒤 터미널에서 rm /path/to/large/file을 실행했지만 No space left on device가 떴음
    2008년의 Unix 스레드와 본질적으로 같은 문제였음: https://www.unix.com/linux/69889-unable-remove-file-using-rm-disk-space-full.html
    echo x > /path/to/large/file도 소용없었고, “드라이브를 지우고 백업에서 복원하라” 말고 다른 제안이 필요했음

    • 1GB 정도의 작은 추가 파티션을 만들어 두는 게 좋은 보험이 될 수도 있음
      예전 Unix 파일시스템이 root용으로 5%를 예약하던 것과 비슷함
    • 그 StackExchange 글에는 이후 다른 잠재적 해결책도 달렸음
      가상 메모리 파티션을 삭제하면, 충분히 크다는 전제에서 파일 삭제가 가능할 만큼의 공간을 되돌려줄 수 있음
    • APFS에서는 그게 그렇게 단순하지 않음
      컨테이너는 실제로 쓰일 때만 할당되기 때문임

  • 인상적임
    rm조차 실패하는 상황은 겪어본 적 없지만, 내부 저장소가 256GB 이하인 현대 Mac을 쓰고 관리하는 불쾌함은 겪어 봤음
    그래서 약 16GB짜리 자리표시자 파일을 만들어 두는 편임
    어차피 공간이 차서 업데이트나 다른 작업을 막으면, ncdu로 외과수술하듯 정리하지 않고도 그 파일만 지우면 됨

  • iPhone에서도 비슷한 일을 겪었음
    디스크가 너무 가득 차서 무언가를 삭제해도 실제로는 아무 일도 안 일어나는 것처럼 보였음
    재부팅하니 로그인할 수 없었고, 다시 재부팅하니 부팅 루프에 빠졌음
    한 번 더 재부팅하자 홈 화면에는 앱 아이콘이 남아 있지만 실제 앱은 사라져 아이콘이 비어 있고 실행도 안 되는 불일치 상태로 부팅됐음
    데이터 무결성이 걱정돼 결국 백업에서 복원했음
    이건 APFS가 기록 시 복사 방식이고 스냅샷을 지원하기 때문에 생긴 결과라고 확신함
    변경이 즉시 영구 반영되지 않고 파일의 이전 버전이 스냅샷에 남는다면, 스냅샷 메타데이터를 위한 공간조차 없을 때 곤란해짐
    디스크 공간이 부족하면 스냅샷을 건너뛸 수도 있겠지만, 그래도 CoW 메타데이터 문제는 남음

    • 나도 정확히 같은 일을 겪었음
      2024년에도 똑똑한 APFS 볼륨 관리 기능이 다 있는데, 사용자 저장공간을 채우기만 해도 iPhone 같은 “봉인된” 기기를 DFU 복구가 필요한 상태로 만들 수 있다는 게 놀라움
      반대로 단일 데이터/부팅 볼륨을 쓰는 Windows 11 업무용 노트북에서 실수로 공간을 꽉 채웠을 때는 여전히 부팅해서 문제를 정리할 수 있었음

  • 얼마 전 Linux 설치의 시스템 파티션에서도 비슷한 상황을 겪었음
    애초에 파티션이 너무 작았고 업데이트가 쌓이면서 무언가를 삭제하기 시작할 공간조차 거의 없어졌음
    아주 조금이라도 삭제할 수 있는 하위 디렉터리를 찾는 데 30분쯤 걸렸음
    안쪽으로 열리는 문을 열 수 없을 만큼 잡동사니로 꽉 찬 방에 갇힌 느낌이었음
    그 작은 시작점에서 점점 더 큰 공간을 삭제할 수 있게 됐고, 마침내 정리한 뒤에는 다시는 그러지 않도록 파티션 크기를 늘렸음

    • 처음부터 파티션을 확장하지 않은 이유가 궁금함
      숙련 사용자라면 파티션 뒤에 항상 약간의 여유 공간을 남겨 두는 게 교훈이어야 할 듯함
답변달기