Fedora Boot / Fuera del espacio

Estoy usando Amahi / Fedora / Greyhole, pero trataré de mantener esta una pregunta general de Linux para guardar explicando cómo funciona Greyhole.

Básicamente, terminé con una unidad de arranque completa (ver / dev / sda3 a continuación). Fedora se ha detenido. No tengo idea de lo que está ocupando todo el espacio. He intentado otras preguntas, pero no he tenido suerte buscando cachés, directorios tmp, etc.

Información de Greyhole potencialmente relevante: El servicio NAS de Greyhole tiene una zona de aterrizaje que monitorea y luego mueve los archivos a un grupo de almacenamiento (mis unidades físicas separadas a continuación). Encontré que la zona de aterrizaje en mi unidad raíz se llenó más rápido de lo que podía borrarse (también accidentalmente sincronicé muchos miles de archivos pequeños en una biblioteca de iPhoto). Arreglé Greyhole al configurar la zona de aterrizaje en otra unidad.

También limpié la zona de aterrizaje en mi unidad de arranque. Pero misteriosamente, mi unidad de arranque permanece llena.

Soy nuevo en Linux, así que por favor ELI5 cualquier suposición

df -h

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        1.5G     0  1.5G   0% /dev
tmpfs           1.5G     0  1.5G   0% /dev/shm
tmpfs           1.5G  8.6M  1.5G   1% /run
tmpfs           1.5G     0  1.5G   0% /sys/fs/cgroup
/dev/sda3        50G   50G   20K 100% /
tmpfs           1.5G   32K  1.5G   1% /tmp
/dev/sdc1       917G   73M  871G   1% /var/hda/files/drives/1tbDisk
/dev/sdd1       459G  328G  108G  76% /var/hda/files/drives/500green
/dev/sdb1       459G  335G  101G  77% /var/hda/files/drives/500blue
/dev/sda1       477M   74M  374M  17% /boot
none            4.0M     0  4.0M   0% /var/spool/greyhole/mem
tmpfs           301M     0  301M   0% /run/user/1000

df -i

Filesystem       Inodes IUsed    IFree IUse% Mounted on
devtmpfs         382198   458   381740    1% /dev
tmpfs            384173     1   384172    1% /dev/shm
tmpfs            384173   514   383659    1% /run
tmpfs            384173    15   384158    1% /sys/fs/cgroup
/dev/sda3        100904 96514     4390   96% /
tmpfs            384173    26   384147    1% /tmp
/dev/sdc1      61054976    25 61054951    1% /var/hda/files/drives/1tbDisk
/dev/sdd1      30531584 88745 30442839    1% /var/hda/files/drives/500green
/dev/sdb1      30531584 88244 30443340    1% /var/hda/files/drives/500blue
/dev/sda1        128016   342   127674    1% /boot
none             384173     1   384172    1% /var/spool/greyhole/mem
tmpfs            384173     4   384169    1% /run/user/1000

sudo du -hxd1 /

17M /etc
100K    /root
1.4G    /var
1.2G    /usr
2.5M    /home
0   /media
0   /mnt
0   /opt
0   /srv
0   /gh
2.6G    /

¿Cómo puedo cazar y solucionar este problema de capacidad?

PD: si alguien pudiera agregar una etiqueta de Greyhole que sería un as.

Resulta que había archivos en el directorio subyacente en el que estaba montando mi recurso compartido de Grehole.

Problema

La unidad de raíz está llena, Amahi se bloquea. SSHing to box y ejecutar 'df -h' muestra solo archivos significativos en / var / hda / files / drives: la ubicación de montaje de sus unidades de datos externas.

Aunque esté montando unidades externas en / var / hda / files / drives sobre una carpeta en esta ubicación, aún podría haber archivos en el sistema de archivos subyacente. En mi caso de una sincronización de Greyhole cuando una nueva unidad externa no se montó correctamente. Con las unidades de datos montadas, es difícil saber qué hay debajo.

Verificar

• Desactivar Greyhole
• Agregue 'nofail' como argumento para fstab para unidades de datos externas para que Fedora no se cuelgue en el arranque sin ellas
• Apague el servidor y desconecte las unidades de datos y reinicie
• Si todavía hay datos accesibles en / var / hda / files / drives, entonces es probable que tenga su causa de por qué su arranque está lleno (también podría simplemente desmontar las unidades externas, pero quería saber con seguridad)

Reparar

• Inicie sesión en la interfaz de usuario web de Amahi y cree un nuevo recurso compartido (no Greyhole), por ejemplo, 'temprecovery'
• Mueva los datos de la unidad de arranque a su recurso compartido temporal a través de SSH, por ejemplo, mv / var / hda / files / drives / your_disk / gh / var / hda / files / temprecovery / gh
• En la red, haga una copia de seguridad de sus archivos y luego bórrelos del recurso compartido. Puede verificar más adelante si los necesita, pero siempre es mejor tener una copia de seguridad.
• En la interfaz de usuario web de Amahi: revise su espacio recuperado en Disco-> Partición. Elimine el recurso compartido temporal que creó.
• Apague el servidor, vuelva a conectar sus unidades, enciéndalo nuevamente, habilite Greyhole y obtenga ganancias.
• Deberá editar el argumento 'nofail' fuera de fstab porque si por alguna razón una unidad de datos no se monta en el arranque en el futuro, no quiere arriesgarse a que los archivos se envíen nuevamente a su unidad interna. Por lo tanto, probablemente sea mejor que el arranque falle si una unidad de datos no se conecta.

Más información en esta publicación aquí .