Ubuntu Server: no se puede eliminar el archivo "x", la estructura necesita limpieza

Tengo un servidor de juegos alojado en mi Ubuntu Server 16.04 y de la nada no puedo iniciarlo / reiniciarlo debido al siguiente archivo:

-????????? ? ?     ?        ?            ? proceduralmap.3000.1499245715.149.sav

Este parece ser el único archivo en fs con esta situación. Ahora, el servidor es un servidor dedicado comprado a un proveedor de hosting. La unidad en la que reside el archivo es un HDD montado en SCSI ( /dev/sdb1).

La df -hTsalida:

Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  3.7G     0  3.7G   0% /dev
tmpfs          tmpfs     744M   81M  663M  11% /run
/dev/sda4      ext4       21G   16G  4.7G  77% /
tmpfs          tmpfs     3.7G   24K  3.7G   1% /dev/shm
tmpfs          tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs          tmpfs     3.7G     0  3.7G   0% /sys/fs/cgroup
/dev/sda3      ext4      946M  143M  739M  17% /boot
cgmfs          tmpfs     100K     0  100K   0% /run/cgmanager/fs
/dev/sdb1      ext2      985G  265G  670G  29% /storage
tmpfs          tmpfs     744M     0  744M   0% /run/user/1011

¿Cuál sería la forma adecuada de reparar / eliminar ese archivo? Preferiría repararlo, pero eliminarlo también lo hará. Ya corrí:

debugfs -w /dev/sdb1

En el que escribí:

clri home/steam/serverfiles/server/rustserver/proceduralmap.3000.1499245715.149.sav

Entiendo, por lo que pude encontrar en la web, que necesitaría ejecutar e2fsck, pero entiendo que primero necesitaría desmontar el disco. No me gustaría hacer eso solo para este archivo, si es posible.

¡Gracias!

¿Qué pasa con el mensaje de error "estructura necesita borrarse"

El error "la estructura necesita borrarse" es el error que los sistemas de archivos (en particular ext4 y xfs) devuelven cuando detectan un problema de corrupción del sistema de archivos. Desafortunadamente, lo único seguro para reparar la corrupción es desmontar el disco y ejecutarlo e2fscken el sistema de archivos. (Técnicamente, no necesitará la -fopción porque el sistema de archivos ya ha detectado problemas y ha marcado el sistema de archivos como problemático. Por lo tanto, cuando lo ejecute e2fsck, realizará un análisis completo para solucionar esos problemas y no necesita la -fopción de forzar un cheque)

Informes de corrupción del sistema de archivos

También debería poder ver los informes de corrupción del sistema de archivos mirando los registros del kernel. (p. ej., ejecutando dmesg, o mirando /var/log/kern.logo donde syslogsea ​​que journaldhaya sido configurado para registrar mensajes del núcleo. Debería ver los mensajes que comienzan EXT4-fs error (device sdXX). Por ejemplo:

EXT4-fs error (device sda3): ext4_lookup:1602: inode #37005: comm docker: deleted inode referenced: 31872136

También puede ver indicaciones de errores mirando dumpe2fs -hel sistema de archivos. Campos de interes:

FS Error count:           25

Esto significa que el kernel ha encontrado inconsistencias del sistema de archivos 25 veces.

First error time:         Thu Jan  1 12:19:59 2015
First error function:     ext4_ext_find_extent
First error line #:       400
First error inode #:      95223833
First error block #:      0

El primer error se encontró el 1 de enero de 2015, a la hora especificada. La función de error y la línea # le permiten identificar exactamente qué parte del código del núcleo encontró el problema. El inodo # le dice qué inodo estuvo involucrado con la inconsistencia del sistema de archivos.

Last error time:          Wed Feb  4 11:57:05 2015
Last error function:      ext4_ext_find_extent
Last error line #:        400
Last error inode #:       95223833
Last error block #:       0

Esto le indica la última vez que el kernel encontró una inconsistencia en el sistema de archivos. Los grandes deltas entre las dos veces significan que alguien no ha estado escaneando sus mensajes del núcleo. Esto se debe a que cada 24 horas, ext4 registrará mensajes de advertencia de que hay un sistema de archivos con daños, y esos mensajes del núcleo se verán así:

EXT4-fs (dm-0): error count since last fsck: 12
EXT4-fs (dm-0): initial error at time 1441536566: ext4_dirty_inode:4655
EXT4-fs (dm-0): last error at time 1441537273: ext4_remount:4550

Nota: el tiempo está en los mensajes del kernel en número de segundos desde el 1 de enero de 1970 a la medianoche UTC. Puede convertir esto a una hora más legible para los humanos utilizando el comando de fecha, por ejemplo:

% date -d @1441536566
Sun Sep  6 06:49:26 EDT 2015

Qué hacer cuando se da cuenta de que su sistema de archivos está dañado

Realmente no desea ejecutar con inconsistencias del sistema de archivos, ya que eso puede conducir a una mayor pérdida de datos. Realmente es una buena idea saltar sobre estos informes, programar el tiempo de inactividad si es necesario y corregirlos lo antes posible.

¿Por qué me e2fsckquejé de que el dispositivo estaba en uso después de desmontarlo?

Finalmente, en respuesta a su pregunta: "Corrí fsckdespués de desmontar y recibí el siguiente error: ¿ /dev/sdb1 is in use.Alguna idea?" Eso probablemente se deba a que tiene uno o más procesos en un espacio de nombres de montaje alternativo, y esos procesos todavía se han /dev/sdb1montado en ese espacio de nombres de montaje. Es posible que desee probar:

grep /dev/sdb1 /proc/*/mounts

Si encuentra procesos que se ejecutan en un espacio de nombres de montaje alternativo, lo más simple es matar y reiniciar esos procesos. (Probablemente sean procesos de daemon). Cuando sale el último proceso que utiliza un espacio de nombres de montaje, el espacio de nombres de montaje desaparece. Y una vez que no haya más espacios de nombres de montaje que se hayan /dev/sdb1montado, realmente se desmontará de verdad.

La forma de pensar en esto es que umountactúa como unlink. Si tiene un archivo con varios enlaces duros, el espacio solo se libera cuando se elimina el último enlace duro. Si tiene varios espacios de nombres activos, cada espacio de nombres actúa efectivamente como un "enlace duro" al soporte en cuestión. Por lo tanto, simplemente desmontar el sistema de archivos en el espacio de nombres de montaje predeterminado no ayudará si algún proceso ha bifurcado el espacio de nombres de montaje predeterminado y se está ejecutando y posiblemente algunos procesos secundarios en esa copia de copia en escritura de su espacio de nombres de montaje principal.