xvda1 está 100% cheio, o que é? como consertar?

Estou executando uma instância do Linux no EC2 (tenho MongoDB e node.js instalado) e estou recebendo este erro:

Cannot write: No space left on device

Acho que rastreei esse arquivo, aqui está a saída df

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda1             1032088   1032088         0 100% /

O problema é que não sei o que é esse arquivo e também não sei se esse arquivo é o problema.

Portanto, minha pergunta é: como faço para corrigir o erro "Sem espaço restante no dispositivo"?

Esse arquivo /é o seu diretório raiz. Se é o único sistema de arquivos que você vê df, então é tudo. Você tem um sistema de arquivos de 1 GB e está 100% cheio. Você pode começar a descobrir como é usado assim:

sudo du -x / | sort -n | tail -40

Você pode substituir /pelos caminhos que ocupam mais espaço. (Eles estarão no final, graças ao sort. O comando pode demorar um pouco.)

Eu sei que estou respondendo neste segmento após quase 5 anos, mas pode ajudar alguém, tive o mesmo problema, tive m4.xlarge instance df -h disse que o / dev / xvda1 estava cheio, - 100%

Filesystem      Size  Used Avail Use% Mounted on
udev            7.9G     0  7.9G   0% /dev
tmpfs           1.6G  177M  1.4G  12% /run
/dev/xvda1      7.7G  7.7G     0 100% /
tmpfs           7.9G     0  7.9G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           7.9G     0  7.9G   0% /sys/fs/cgroup
tmpfs           1.6G     0  1.6G   0% /run/user/1000

eu tentei resolvê-lo aqui estão os passos

sudo find / -type f -printf '%12s %p\n' 2>/dev/null|awk '{if($1>999999999)print $0;}'

Ajudou-me a saber que era o contêiner do docker que estava falando todo o meu espaço, então eu empurrei todo o meu contêiner para o meu registro do docker e fiz sudo rm -rf / var / lib / docker / limpou meu espaço :) espero que ajude alguém :)

Se você estiver executando uma instância de inicialização do EBS (recomendado), poderá aumentar o tamanho do volume raiz (/) usando o procedimento descrito neste artigo:

Redimensionando o disco raiz em uma instância EC2 de inicialização do EBS em execução
http://alestic.com/2010/02/ec2-resize-running-ebs-root

Se você estiver executando uma instância de armazenamento de instância (não recomendado), não poderá alterar o tamanho do disco raiz. Você precisa excluir ou mover arquivos para armazenamento efêmero (por exemplo, / mnt) ou anexar volumes EBS e mover arquivos para lá.

Aqui está um artigo que escrevi que descreve como mover um banco de dados MySQL do disco raiz para um volume EBS:

Executando o MySQL no Amazon EC2 com EBS
http://aws.amazon.com/articles/1663

... e considere mudar para instâncias de inicialização do EBS. Há muitas razões pelas quais você se agradecerá mais tarde.

Recentemente, deparei com esse problema no Amazon Linux. Minha fila de e-mail de saída do crontab /var/spool/clientmqueueera de 4,5 GB.

Eu resolvi isso por:

1. Localizando arquivos grandes: sudo find / -type f -size +10M -exec ls -lh {} \;
2. Excluindo arquivos grandes: /bin/rm -f <path-to-large-file>
3. Reinicie a instância do servidor

Problema resolvido!

Acabei de resolver esse problema executando este comando:

sudo apt autoremove

e muitos pacotes antigos foram removidos, liberando 5 gigabytes, por exemplo, havia muitos pacotes como este "linux-aws-headers-4.4.0-1028"

Poderia ser de Jenkins ou Docker. Para resolver isso, limpe os logs do Jenkings e defina seu tamanho .