Por que os discos rígidos vivem cheios

• Mesmo aumentando a capacidade de armazenamento várias vezes, o uso cresce junto; em uma enquete no Mastodon com 81 participantes, cerca de metade também usava mais de 75% do disco
• Isso pode ser explicado em parte pela lógica da entropia, já que há mais maneiras de chegar a um estado cheio do que a um estado vazio, mas isso não explica completamente o comportamento dos usuários
• Adiar a organização até chegar ao limite e apagar apenas o necessário no momento mantém o disco em estado de saturação constante
• Software lento, dívida técnica acumulada, estradas congestionadas e agendas apertadas também seguem o mesmo padrão de só receberem atenção depois que a dor atinge um ponto crítico
• Definir restrições artificiais menores que o total de recursos, como um orçamento, pode evitar otimizações prematuras sem deixar o problema chegar ao limite

---

Por que o espaço de armazenamento continua ficando cheio

• A unidade raiz tem apenas 17 GB livres de 0,47 TB disponíveis, ou seja, 3% de espaço livre; a unidade adicional de 12 TB também tem só 140 GB restantes, cerca de 1%
• A capacidade de armazenamento aumentou várias vezes, dobrando de cerca de 80 MB nos anos 1990 para dezenas de TB, mas ainda assim continua quase toda em uso
  • O fato de já existirem há muito tempo programas para encontrar arquivos a serem apagados também mostra como esse problema persiste
• Entre 81 respondentes de uma enquete no Mastodon, cerca de metade usava mais de 75% do disco, indicando que discos cheios são mais comuns do que discos com muito espaço livre
• Como existem mais estados possíveis para um disco cheio do que para um disco vazio, é possível fazer uma interpretação baseada em entropia: se os estados mudarem aleatoriamente sem considerar a quantidade armazenada, a tendência é caminhar para a saturação
• Porém, o disco não parece ser um problema até que não seja mais possível armazenar mais nada; nesse ponto, a bagunça já está grande demais para decidir facilmente o que pode ser apagado
  • O usuário organiza apenas o suficiente para ganhar tempo e então para, fazendo o disco voltar rapidamente ao limite
  • Mesmo que a capacidade de armazenamento aumente em várias ordens de magnitude, esse comportamento não muda

O limite da dor e as restrições artificiais

• O padrão de adiar a reação até que o problema se torne insuportável se repete em várias áreas
  • O software não é otimizado até ficar lento demais, então em geral permanece lento o tempo todo
  • A dívida técnica se acumula até que trabalhar no código fique doloroso e o refactoring se torne inevitável
    • Desenvolvedores menos experientes às vezes simplesmente recomeçam do zero, o que deixa a maioria das bases de código desorganizada
  • As malhas viárias só são ampliadas depois de ficarem congestionadas além do aceitável
  • A dieta só é controlada quando chega a hora de comprar calças maiores
  • Mesmo ao sair de um emprego em tempo integral para trabalhar por conta própria e perder obrigações e ordens, a agenda continua tão cheia quanto antes, às vezes até mais
• Esperar até o limite faz com que a quantidade de trabalho a resolver seja muito maior do que se o problema fosse tratado aos poucos durante o processo, mas, por outro lado, otimização prematura também não é desejável
• Para equilibrar os dois problemas, é possível usar o Jevons paradox e impor uma restrição prática menor que o total de recursos disponíveis, otimizando dentro desse limite
  • Em finanças pessoais isso é chamado de orçamento, mas em outras áreas o mesmo princípio é repetidamente ignorado
  • Se você implantar software em um Raspberry Pi, usar diretamente e otimizar ali, ele também vai rodar rápido em um Threadripper
  • Uma base de código navegável no Vim de um terminal 80×25 também será navegável em uma IDE moderna e poderosa
• Quando recursos e funcionalidades aumentam, parece que será possível fazer mais coisas, mas na prática isso às vezes apenas faz com que a mesma coisa seja feita com um custo maior

[GN⁺]

Comentários no Lobste.rs

• Ao criar software desktop multiplataforma, é muito mais fácil resolver os problemas antes que eles cheguem ao limite. Por isso, adotamos o princípio de sempre compilar e executar no Windows, Mac e Linux desde o primeiro commit no Git
  Foi uma restrição dolorosa, mas eliminou por completo uma categoria de solicitações de suporte ao cliente. Concorrentes costumam oferecer suporte só a Mac e Linux, ou lançar apenas para Windows e prometer suporte a UNIX; ver eles sofrendo com perguntas incessantes dos usuários como “quando sai para Linux?” dá um certo alívio. Ainda recebemos perguntas do tipo “quando sai o port para BSD?”, mas isso é administrável
  • Tenho a impressão de que a proporção de pessoas que pedem port para BSD e também se oferecem para ajudar diretamente deve ser excepcionalmente alta; fico curioso se é verdade
• Concordo totalmente que, se um software foi implantado e usado pessoalmente em um Raspberry Pi, ele também vai rodar rápido em um Threadripper. Otimizações de baixo nível voltadas a CPUs modernas, como previsão de desvios, latência de acesso à memória e inlining, foram eficazes em praticamente qualquer CPU lançada nos últimos 15 a 20 anos
  Instruções SIMD mais recentes também são interessantes, mas uso como referência para todas as otimizações um MacBook Pro de 2015 com Intel Haswell e AVX2. Código que funciona bem nesse ambiente continua funcionando igualmente bem hoje
• É uma perspectiva interessante. No momento estou usando 97% de um disco de 1 TB
  Cada vez que passei de 256 GB para 512 GB, a quantidade de conteúdo que armazeno também aumentou. Sempre há mais repositórios para clonar, músicas para baixar, vídeos do YouTube e filmes para guardar; e, ao passar de 720p para 1080p e 4K, os tamanhos dos arquivos também crescem. Jogos também estão ficando tão enormes que, para instalar outro jogo da Steam, preciso apagar algum. No fim, fico me perguntando se é apenas o fenômeno simples de encher o cesto atual o máximo possível até conseguir um cesto maior
  • Fico curioso se clonar repositórios aqui é simplesmente para arquivamento offline ou bookmark, ou se é algo necessário no processo de instalação de software
    Eu marco com estrela repositórios de que gosto no GitHub, Codeberg etc. Espero que um dia, como em um fediverso, seja possível compartilhar estrelas entre diferentes forjas Git, sem precisar manter contas no GitHub, GitLab e Codeberg. Gostaria de saber se você clona o código por conta própria como precaução contra o repositório desaparecer ou ficar inacessível
• A partição /nix quase sempre fica acima de 90% cheia, exceto logo depois de uma instalação totalmente nova. O Nix mostra claramente a perspectiva dos desenvolvedores de recuperar disco por garbage collection só quando precisa de espaço, de forma parecida com gerenciamento de memória. Artefatos intermediários de build de várias versões também ocupam uma quantidade enorme de espaço
  O servidor de mídia não fica cheio porque uso um RAID heterogêneo que cresce lentamente ao longo dos anos, substituindo drives antigos que falham por drives maiores de preço parecido. Também desisti da tentativa de digitalizar todos os CDs e DVDs da casa. CDs de áudio com compressão sem perdas e jogos de Wii valem a pena, mas HD-DVD não compensa de jeito nenhum
  • CDs e DVDs já não são mídias digitais?
• Eu executo o rootfs em tmpfs. O disco rígido para armazenamento persistente fica quase vazio, mas o tmpfs continua ficando bagunçado de maneiras difíceis de entender. Quando falta RAM, reinicio o sistema para recuperar o espaço temporário
  Dá trabalho garantir que materiais valiosos não desapareçam, normalmente registrando-os no Nix e preservando-os em pastas de projeto que usam Git. Manter esse dispositivo de máquina do tempo por anos exigiu um esforço enorme, mas parece ser o único jeito de gerenciar uma escala e complexidade que crescem sem parar
• Isso me lembra a Lei de Parkinson: “o trabalho se expande de modo a preencher todo o tempo disponível para sua conclusão”
• Parece que a pessoa não gosta de viver no limite. Uma vida feliz é aquela em que você está ocupado, mas não apressado; o software é rápido na medida exata do necessário; dinheiro e necessidades se encontram no meio; e há exatamente a quantidade certa de espaço livre no disco rígido