xvda1 está 100% lleno, ¿qué es? ¿como arreglar?

Estoy ejecutando una instancia de Linux en EC2 (tengo MongoDB y node.js instalados) y obtengo este error:

Cannot write: No space left on device

Creo que lo he rastreado hasta este archivo, aquí está la salida de df

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

El problema es que no sé qué es este archivo y tampoco sé si este archivo es el problema.

Entonces mi pregunta es: ¿Cómo soluciono el error "No queda espacio en el dispositivo"?

Ese archivo /es tu directorio raíz. Si es el único sistema de archivos que ves df, entonces es todo. Tienes un sistema de archivos de 1GB y está 100% lleno. Puedes comenzar a descubrir cómo se usa así:

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

Luego puede reemplazar /con los caminos que ocupan más espacio. (Estarán al final, gracias a sort. El comando puede tardar un tiempo).

Sé que estoy respondiendo en este hilo después de casi 5 años, pero podría ayudar a alguien, tuve el mismo problema, tuve m4.xlarge instancia df -h me dijo que / dev / xvda1 estaba lleno, - 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

Traté de resolverlo aquí están los pasos

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

Me ayudó a saber que era el contenedor de Docker el que estaba hablando todo mi espacio, así que empujé todo mi contenedor a mi registro de Docker y luego sudo rm -rf / var / lib / docker / despejó mi espacio :) espero que ayude a alguien :)

Si está ejecutando una instancia de arranque de EBS (recomendado), puede aumentar el tamaño del volumen raíz (/) utilizando el procedimiento que describo en este artículo:

Cambiar el tamaño del disco raíz en una instancia EBS Boot EC2 en ejecución
http://alestic.com/2010/02/ec2-resize-running-ebs-root

Si está ejecutando una instancia de tienda de instancias (no recomendado), entonces no puede cambiar el tamaño del disco raíz. Tiene que eliminar archivos o mover archivos al almacenamiento efímero (por ejemplo, / mnt) o adjuntar volúmenes EBS y mover archivos allí.

Aquí hay un artículo que escribí que describe cómo mover una base de datos MySQL del disco raíz a un volumen EBS:

Ejecutar MySQL en Amazon EC2 con EBS
http://aws.amazon.com/articles/1663

... y considere pasar a las instancias de arranque de EBS. Hay muchas razones por las que te lo agradecerás más tarde.

Recientemente me he encontrado con este problema en Amazon Linux. Mi cola de correo electrónico saliente de crontab /var/spool/clientmqueueera de 4.5 GB.

Lo resolví por:

1. Localización de archivos grandes: sudo find / -type f -size +10M -exec ls -lh {} \;
2. Eliminar archivos grandes: /bin/rm -f <path-to-large-file>
3. Reiniciar instancia del servidor

¡Problema resuelto!

Acabo de resolver ese problema ejecutando este comando:

sudo apt autoremove

y se eliminaron muchos paquetes antiguos, liberando 5 gigabytes, por ejemplo, había muchos paquetes como este "linux-aws-headers-4.4.0-1028"

Podría provenir de Jenkins o Docker. Para resolver eso, debe limpiar los registros de Jenkings y establecer su tamaño .