Um disco tão cheio que não dava para restaurar

• O volume de inicialização de um M2 MacBook Pro ficou tão cheio durante o download de um jogo no Steam que restaram apenas 41 KB, deixando o macOS em um estado em que nem conseguia apagar arquivos
• Esvaziar a Lixeira pelo Finder, usar rm e find -exec rm no Terminal, e até apagar snapshots do Time Machine pelo Utilitário de Disco falharam com erros do tipo “No space left on device”
• Após reiniciar, a inicialização também parou no meio; mesmo usando o recoveryOS e o Share Disk do Apple silicon para montar o disco em outro Mac, não foi possível forçar a exclusão
• Depois de apagar o drive e reinstalar o macOS, houve tentativa de restauração pelo Time Machine, mas surgiram novos problemas: interrupção da restauração no Ventura, diferença de versão entre o Sonoma 14.4 e o 14.3.1 anterior, e falha ao montar via SMB/Samba na rede
• No fim, a imagem de disco mais recente do Time Machine foi copiada para um SSD externo de 1 TB, e os arquivos do diretório pessoal e apps foram recuperados manualmente; quando falta de espaço e falhas de restauração de backup se combinam, até usuários experientes têm dificuldade para lidar com a situação

---

Mac sem espaço, a ponto de nem conseguir apagar arquivos

• O armazenamento de um M2 MacBook Pro lotou enquanto baixava um jogo comprado legalmente no Steam
• Mesmo com o drive perigosamente cheio, o macOS não interrompeu o grande download do Steam, e restaram apenas 41 KB no volume de inicialização
• A maioria dos arquivos importantes estava na nuvem, e não havia uma situação em que fosse indispensável preservar arquivos locais grandes
• O problema não era uma simples falta de espaço, mas um estado em que o sistema operacional não conseguia apagar arquivos de nenhuma forma

Causas suspeitas: download do Steam e snapshots locais do Time Machine

• É possível que, por causa da conexão de internet gigabit e dos arquivos grandes do Steam, o macOS não tenha conseguido controlar o aumento do uso de armazenamento
• Ao mesmo tempo, havia a suspeita de que o macOS estava criando snapshots locais do Time Machine
• O macOS mantém snapshots para oferecer backups locais das últimas 24 horas, mesmo durante backups para um destino externo ou de rede do Time Machine
• O arquivo do Steam parecia, por fora, um único arquivo gigantesco, mas pode ter sido tratado de forma diferente do ponto de vista do Time Machine
• Arquivos locais reais e snapshots criados de forma especial podem ter entrado em conflito, mas a causa exata não foi confirmada

Todas as tentativas de apagar falharam

• Esvaziar a Lixeira no Finder falhou em File > Empty Trash
  • A mensagem de erro era “The operation can’t be completed because the disk is full”
• O Terminal abria, mas o comando Unix padrão rm não funcionava
  • A mensagem de erro era “No space left on device”
  • Uma alternativa baseada em find, que localizava arquivos grandes e executava rm com a opção -exec, também falhou
• Também foi feita uma tentativa no Utilitário de Disco de selecionar e apagar snapshots do Time Machine no volume de inicialização APFS, mas ela encontrou a mesma limitação
  • Em geral, snapshots ocupam apenas o espaço necessário para as diferenças em relação ao snapshot anterior
  • Mesmo nesse caso, ocorreu o erro “no space left”

Reinicialização, recoveryOS e Share Disk também não resolveram

• Foi feita uma reinicialização esperando que caches fossem limpos, mas o Mac não inicializava mais normalmente
• O estado se repetia: a barra de progresso chegava a cerca da metade e então falhava
• No recoveryOS, foram tentadas operações relacionadas a reparo pelo Utilitário de Disco e reinstalação com o volume de inicialização desmontado, mas os comandos no Terminal geravam o mesmo erro
• Tentou-se montar o drive em outro Mac usando o recurso Share Disk do Apple silicon
  • A tentativa de forçar a exclusão por meio do compartilhamento de disco baseado em Samba falhou

Problemas durante a restauração pelo Time Machine

• Havia um backup do Time Machine, incluindo o da noite anterior, e como a maior parte dos dados importantes estava na nuvem, a situação não exigia obsessão por uma recuperação completa
• Primeiro, o drive foi apagado e o Ventura, sistema padrão de fábrica do MacBook Pro, foi reinstalado pelo macOS Recovery
• Ao iniciar o macOS, o Migration Assistant acessou o backup de rede do Time Machine, e alguns itens de restauração foram desmarcados para deixar espaço suficiente livre
• Durante a restauração, o Ventura travou no meio e depois não retomou
• Em seguida, o Mac foi atualizado para o Sonoma, a versão do macOS que estava em uso na época
  • A atualização foi bem-sucedida, mas a versão instalada era a 14.4
  • No Mac original estava instalada a 14.3.1
  • Ao tentar restaurar diretamente durante a etapa inicial, a diferença de versão impediu o processo

Problema do Sonoma 14.4 ao montar Time Machine pela rede

• Após criar uma conta de usuário padrão no Sonoma, o Migration Assistant foi executado
• O Migration Assistant encontrou e reconheceu o Mac de rede que gerenciava o backup do Time Machine
• Porém, não conseguiu montar o volume de backup da criança, e “Mount failed” aparecia repetidamente
• Buscas em fóruns indicaram que, no Sonoma, o procedimento de montagem em rede baseado em SMB/Samba estava quebrado para restaurações do Time Machine, sem que houvesse uma solução encontrada
• Esse problema parecia continuar válido também no macOS 14.4

Recuperação final: copiar o backup para um SSD externo e migrar manualmente

• A restauração completa pelo Migration Assistant foi abandonada, e apenas os apps e arquivos necessários foram recuperados manualmente
• No Mac que gerenciava o backup de rede, a imagem de disco daquele computador foi aberta com duplo clique, e a senha do volume do Time Machine foi inserida
  • O volume de rede do Time Machine sempre tinha sido configurado com uma senha separada
• O ícone de disco com o timestamp mais recente foi localizado e copiado para um SSD externo de 1 TB vazio
• O SSD externo foi conectado à conta temporária no MacBook Pro para transferir os arquivos necessários
  • A maior parte do conteúdo das pastas do diretório pessoal foi incluída
  • Arquivos grandes de download e alguns vídeos desnecessários foram excluídos
• O SSD externo será mantido por algum tempo para permitir recuperação adicional caso algum arquivo esteja faltando

Alternativas que não foram tentadas

• O drive do Time Machine usado para o backup de rede poderia ter sido desmontado no Mac que gerenciava os backups e conectado diretamente ao Mac da criança
  • Nesse caso, é possível que ele aparecesse como ponto de partida no Migration Assistant
• Também seria possível copiar o disco virtual da imagem de disco montada do Time Machine para fazer com que o SSD externo de 1 TB parecesse um volume de origem do Mac
  • Não foi confirmado se esse método realmente funcionaria
  • Se tivesse dado certo, talvez fosse possível restaurar diretamente pelo Migration Assistant
• Como já haviam se acumulado horas de trabalho e mais de um dia de tentativas, e o usuário não fazia questão de uma recuperação perfeita diretório por diretório, não foram feitos experimentos adicionais

[GN⁺]

Opiniões no Hacker News

• Talvez tivesse sido melhor se o autor tivesse inicializado o Mac por um dispositivo de armazenamento externo e depois apagado os arquivos desnecessários do disco interno: Use an external storage device as a Mac startup disk
  Foi surpreendente descobrir que, em Macs com Apple Silicon, nem todas as portas são equivalentes ao fazer boot externo
  Ao instalar o macOS em um dispositivo de armazenamento, em notebooks Mac é preciso evitar a porta USB-C mais à esquerda entre as portas do lado esquerdo; em iMac/Mac mini/Mac Studio/Mac Pro, também há portas USB-C específicas a evitar conforme o modelo
  Dizem que, depois que a instalação termina, pode-se conectar em qualquer porta

  • Já foi feita uma tentativa praticamente igual ao que foi sugerido
    O autor inicializou pelo recoveryOS, que fica em uma partição separada, e tentou apagar arquivos da partição principal do sistema, mas o rm falhou com o mesmo erro No space left on device
    Então talvez a abordagem mencionada por outras pessoas, de truncar o arquivo com echo -n >file, pudesse ter funcionado
  • Se o próprio sistema de arquivos entrou em deadlock, apagar arquivos por meio do driver do sistema de arquivos não vai funcionar, independentemente de onde o boot tenha sido feito
  • Não funcionou nem pelo recoveryOS nem pelo modo Mac Share Disk/Target Disk; fico curioso por que acham que esse método funcionaria
  • Um comentário desses deve ser muito bem-vindo para alguém que, daqui a 8 anos, esteja pesquisando para resolver um problema em um Mac antigo da época
  • Fico curioso se alguém sabe por que não se deve usar a primeira porta USB-C ao criar um sistema operacional inicializável em um notebook Mac

• Com um pouco de conhecimento sobre a estrutura de discos HFS+, dá para chutar que o arquivo de journal também ficou cheio e que a exclusão exige escrever no journal e, em alguns casos, expandi-lo; então parece ter entrado em um estado estranho em que o próprio ato de apagar exige mais espaço, ainda que temporariamente
  O macOS continuou gravando arquivos até restarem apenas 41 KB no drive
  Já enchi por acidente NTFS e FAT32 até 0 byte, e mesmo assim ainda era possível apagar algo
  Vasculhando fóruns, parece que o Sonoma quebrou o procedimento de montagem de rede baseado em SMB/Samba para restauração do Time Machine, e aparentemente ainda não há solução no 14.4
  Pela minha experiência, o SMB passou a ser pouco confiável e cheio demais de bugs por volta do 10.12~10.13, e agora parece que a Apple nem se importa mais se isso funciona
  Não quero nem imaginar o que pessoas sem décadas de experiência com Mac fariam ao se deparar com esse tipo de falha sistêmica em cadeia
  Não tenho décadas de experiência com Mac, mas, numa situação dessas, eu teria tentado primeiro fsck; acho estranho isso não ter sido mencionado aqui
  Se não fosse possível copiar o conteúdo do disco para outro disco, formatar e devolver tudo, eu provavelmente consultaria a documentação do APFS (https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf) e tentaria descobrir, com dd e um editor hexadecimal, o que corrigir para criar algum espaço livre

  • Isso vale para sistemas de arquivos com journaling; em um sistema de arquivos com cópia na gravação (CoW), toda alteração é feita criando uma nova árvore de arquivos e depois fazendo a raiz apontar para essa nova árvore
    Depois, a coleta de lixo encontra arquivos que não pertencem mais à árvore ativa e devolve esse espaço ao armazenamento
    Em geral, as alterações são agrupadas para manter o volume de mudanças na árvore em um nível administrável, e, graças a esse desenho, snapshots do sistema de arquivos viram apenas outra referência a uma árvore específica
    Esse processo exige espaço, mas sistemas de arquivos CoW normalmente reservam armazenamento de emergência justamente por esse motivo
  • A Apple trocou o Samba por uma implementação própria há muito tempo, depois que o Samba adotou a 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
  • Como é típico da Apple, o desempenho do SMB era terrivelmente lento alguns anos atrás e, mesmo recentemente, é apenas tolerável, muito mais lento que NFS no mesmo hardware ou, ironicamente, que Appleshare
    Alguns anos atrás, em um Hackintosh conectado por 10GbE a um NAS grande, medi com o BlackMagic Disk Speed Test: o SMB no Windows deu 900 MB/s, o SMB no macOS deu 200 MB/s, e NFS e AFP no macOS deram ambos 1000 MB/s
    Recursos do macOS relacionados a trabalho profissional são, infelizmente, ridículos
    Dizem que o AFP morreu, mas no meu Mac Pro ele ainda funciona bem como cliente, e o desempenho é tão melhor que o SMB que chega a parecer comédia
  • Não é divertido quando acontece com você, mas a mesma coisa também é possível com BTRFS e ZFS
    Se encher até o limite, podem surgir problemas
    O BTRFS tenta alternar para somente leitura enquanto ainda resta espaço de metadados, permitindo remontar em modo seguro e apagar alguma coisa, mas não é uma proteção perfeita
    Até onde sei, NTFS e FAT32 não são sistemas de arquivos com journaling
  • Até agora, esta parece ser a única explicação técnica realmente adequada

• Passei por isso no meu primeiro emprego
  Por engano, enchi o cluster com arquivos de job, e o administrador do sistema começou a mandar e-mails dizendo para eu corrigir rápido, mas rm não funcionava
  Foi aí que aprendi que, mesmo quando não dá para apagar, truncar o arquivo geralmente funciona; então, quando rm foo não funciona, muitas vezes cat /dev/null > foo resolve

  • No shell, :>filepath costuma funcionar
    Só que alguns sistemas de arquivos podem nem permitir isso
    Nesses casos, é preciso torcer para que o sistema de arquivos suporte expansão de tamanho, redução de tamanho, armazenamento temporário adicional, ou que o subsistema subjacente permita adicionar/remover armazenamento de apoio
    Como no btrfs, pode ser necessário um comando separado para voltar à estrutura de um único dispositivo de bloco
  • Alguns anos atrás, havia uma situação em que uma infraestrutura crítica, que precisava sempre conseguir escrever no sistema de arquivos, podia entrar em deadlock e ficar irrecuperavelmente quebrada
    Então fiz o processo de backup mandar periodicamente dados lixo diretamente para /dev/null, e esse hack sujo provavelmente ainda está rodando
    /dev/null é meio mágico e vale a pena ler sobre ele
  • Na verdade, só >file já basta
  • Mas, como em vários comentários aqui, também há situações em que até truncar falha
    Os formatos de sistemas de arquivos do século XXI são muito mais complexos que o UFS, e recursos como snapshots e journaling criam novas formas de o sistema de arquivos entrar em deadlock sozinho
  • Uma vez deixei o nível de log do Samba alto demais por causa de depuração e esqueci de voltar, enchendo o SSD raiz em ZFS com um arquivo de log gigantesco
    No fim, tive que recuperar com truncate
    Eu sabia que o ZFS era melhor para esse tipo de situação, mas a sensação de afundamento do “ah... droga” quando você percebe que realmente fez besteira foi a mesma

• O Time Machine parece piorar continuamente
  Não entendo por que não há incentivo para torná-lo estável e funcionando direito
  Depois de passar por sparse bundles corrompidos que exigem começar um novo backup, ou por falhas do recurso, agora sinto que quase não vale a pena configurar o Time Machine
  É um contraste total com os backups do iOS/iPadOS, que sempre funcionaram bem

  • Porque eles não vendem mais o Time Capsule
    A Apple quer que as pessoas façam backup de tudo no iCloud para aumentar a receita de serviços
  • Do ponto de vista de quem não usa Mac, isso soa como um bug catastrófico e indefensável que teria provocado críticas enormes se fosse em um sistema operacional de desktop com um mascote pinguim ou com sede em Washington
  • Foram vezes demais em que o Time Machine decidiu do nada que não queria mais trabalhar, e eu tive que apagar o backup e começar de novo
  • O controle de qualidade do macOS vem caindo desde que Scott Forstall foi demitido e, para falar a verdade, mesmo na época dele não era algo impressionante
  • Minha experiência é diferente
    Uso o Time Machine há anos em vários Macs sobre compartilhamentos Samba, e só vi melhorias
    Antes, os sparse bundles do Time Machine corrompiam com frequência e eu precisava recriá-los ou restaurar um snapshot ZFS anterior para continuar
    Acho que naquela época era AFP, não SMB
    Recentemente, não tive esse problema em nenhum dispositivo, embora eu tenha ativado em smb.conf algumas flags específicas recomendadas para backups do Time Machine

• Em contrapartida, o ZFS tem slop space para evitar que o sistema de arquivos trave quando o espaço acaba durante uma operação grande
  Por padrão, ele reserva 3,2% do espaço do volume, até um máximo de 128 GB
  Assim, se você alterar o ajuste do kernel Linux spa_slop_shift para reduzir o slop space, pode recuperar até 128 GB de espaço bônus para concluir com sucesso uma operação de exclusão de arquivos: https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#spa-slop-shift

  • Exato
    Por esse motivo, reservar uma certa porcentagem do espaço em disco era um recurso comum de sistemas de arquivos “de verdade” décadas antes de ZFS ou Linux existirem
    É parecido com o fato de que a maioria dos programas de terminal shareware para MS-DOS nos anos 1980 baixava arquivos muito bem em conexões de largura de banda limitada, enquanto o MS Windows atual é péssimo até nessa tarefa que deveria ser trivial
  • O ext4 tem o mesmo recurso, só que o chama de reserved blocks
    Para detalhes, veja man tune2fs
    A maioria dos outros sistemas de arquivos modernos, e muitos nem tão modernos, também tem algo parecido
    Pelo que me lembro, o UFS do SunOS dos anos 1980 também tinha: https://en.wikipedia.org/wiki/SunOS

• As pessoas têm dificuldade para entender a ideia de que apagar algo pode, na prática, exigir mais espaço, temporária ou permanentemente
  Outros comentários explicaram em detalhes por que sistemas de arquivos modernos, com snapshots, journaling e afins, precisam alocar espaço livre para executar uma exclusão
  Em outras áreas, de forma parecida, durante a primeira década da Wikipedia era comum ter que explicar que tentar apagar páginas para economizar espaço nos servidores na verdade produzia o efeito oposto
  Isso porque, pelo menos desde cerca de 2004, uma exclusão adicionava um registro ao banco de dados interno
  No formato de arquivo ZOO de Rahul Dhesi, excluir uma entrada era apenas definir uma flag no registro de cabeçalho, e também havia o versionamento de arquivos ao estilo VMS, em que adicionar uma nova versão não sobrescrevia a anterior
  Na época do MS/DR/PC-DOS e do FAT, se um utilitário de recuperação de arquivos apagados estivesse instalado, apagar um arquivo podia exigir mais espaço para salvar uma nova entrada em um banco de dados com informações de recuperação
  Alguns utilitários antigos de compressão de disco comprimiam até os metadados, então também eram possíveis situações raras em que uma alteração nos metadados mudava a taxa de compressão e aumentava de fato o tamanho do volume visto externamente
  A ideia de que apagar libera espaço é muito difundida, mas, a rigor, nem sempre é verdadeira

• Em outubro de 2018, passei pelo mesmo problema e deixei registrado na pergunta do Stack Overflow abaixo
  Por sorte, eu tinha uma partição APFS extra que podia remover, então consegui liberar espaço em disco
  Levei bastante tempo para descobrir isso e, nesse meio-tempo, entrei em pânico de verdade
  https://apple.stackexchange.com/questions/338721/disk-full-terminal-in-recovery-mode-won-t-delete-files-boot-kernel-panics
  Logo depois de atualizar para o macOS Mojave, eu estava criando um .dmg, enchi o disco e o sistema travou
  Ao reiniciar, deu kernel panic; então inicializei em modo de recuperação, montei o disco e executei rm /path/to/large/file no terminal, mas apareceu No space left on device
  Era essencialmente o mesmo problema de uma thread de Unix de 2008: https://www.unix.com/linux/69889-unable-remove-file-using-rm-disk-space-full.html
  echo x > /path/to/large/file também não adiantou, e eu precisava de alguma sugestão além de “apague o drive e restaure a partir do backup”

  • Criar uma partição extra pequena, de cerca de 1 GB, pode ser uma boa apólice de seguro
    Parecido com o modo como sistemas de arquivos Unix antigos reservavam 5% para o root
  • Naquele post do StackExchange, outras possíveis soluções foram acrescentadas depois
    Excluir a partição de memória virtual pode devolver espaço suficiente para permitir a exclusão de arquivos, desde que ela seja grande o bastante
  • No APFS, isso não é tão simples assim
    Porque os contêineres só são alocados quando de fato são usados

• Impressionante
  Nunca passei por uma situação em que até o rm falhasse, mas já vivi o incômodo de usar e administrar Macs modernos com armazenamento interno de 256 GB ou menos
  Por isso costumo criar um arquivo placeholder de cerca de 16 GB
  De qualquer forma, se o espaço encher e bloquear atualizações ou outras tarefas, basta apagar esse arquivo, sem precisar fazer uma limpeza cirúrgica com ncdu

  • Vi que o CockroachDB faz a mesma coisa ao iniciar um nó: https://www.cockroachlabs.com/docs/v23.2/cluster-setup-troubleshooting#automatic-ballast-files
  • A grande vantagem de um arquivo placeholder é que, quando necessário, você pode liberar esse espaço e ganhar tempo para executar uma solução de longo prazo
    Por exemplo, comprar um drive novo quatro vezes maior pelo custo de uma hora de um funcionário ou do equipamento

• Passei por algo parecido também no iPhone
  O disco estava tão cheio que, mesmo apagando alguma coisa, parecia que nada acontecia de fato
  Ao reiniciar, não consegui fazer login; ao reiniciar de novo, ele entrou em loop de boot
  Depois de mais uma reinicialização, ele iniciou em um estado inconsistente: os ícones dos apps continuavam na tela inicial, mas os apps reais tinham desaparecido, deixando ícones vazios que não abriam
  Preocupado com a integridade dos dados, acabei restaurando a partir de um backup
  Tenho certeza de que isso é consequência de o APFS usar copy-on-write e oferecer suporte a snapshots
  Se as alterações não são persistidas imediatamente e versões anteriores dos arquivos permanecem em snapshots, a situação fica complicada quando não há espaço nem para os metadados dos snapshots
  Até seria possível pular snapshots quando o espaço em disco estivesse baixo, mas o problema dos metadados de CoW ainda permaneceria

  • Aconteceu exatamente a mesma coisa comigo
    Mesmo em 2024, com todos os recursos inteligentes de gerenciamento de volumes do APFS, é surpreendente que simplesmente preencher o armazenamento do usuário possa deixar um dispositivo “selado” como o iPhone em um estado que exige recuperação DFU
    Em contraste, quando lotamos por engano o espaço de um notebook corporativo com Windows 11 usando um único volume de dados/boot, ainda foi possível inicializar e resolver o problema

• Há pouco tempo passei por uma situação parecida na partição de sistema de uma instalação Linux
  Para começo de conversa, a partição era pequena demais e, com o acúmulo de atualizações, quase não sobrou espaço nem para começar a apagar algo
  Levei cerca de 30 minutos para encontrar um subdiretório do qual eu pudesse apagar qualquer coisinha
  Parecia estar preso em um quarto tão cheio de tralha que a porta, que abria para dentro, não conseguia abrir
  A partir daquele pequeno ponto inicial, consegui apagar espaços cada vez maiores e, por fim, depois da limpeza, aumentei o tamanho da partição para nunca mais passar por isso

  • Fico curioso para saber por que você não expandiu a partição desde o começo
    Para usuários experientes, a lição deveria ser sempre deixar um pouco de espaço livre depois da partição