No se puede eliminar el directorio de Linux - recursión infinita

8

Tenemos un montaje NFS en una VM RHEL6 que admite nuestro servidor de control de versiones; recientemente, uno de los repositorios se volvió un poco loco y esto es lo que encontré en el servidor:

ls -latri repo.git/refs/heads/

total 28
5551210 drwxr-xr-x. 2 git git 8192 Jun  1 21:21 .
5551210 drwxr-xr-x. 2 git git 8192 Jun  1 21:21
5551210 drwxr-xr-x. 2 git git 8192 Jun  1 21:21
5551209 drwxr-xr-x. 3 git git 4096 Jun  1 22:09 ..

Cuando corro treecontra el directorio, parece ser infinitamente recursivo, por ejemplo:

repo.git/refs/heads/
├──
│   ├──
│   │   ├──
│   │   │   ├──
│   │   │   │   ├──
│   │   │   │   │   ├──
│   │   │   │   │   │   ├──
│   │   │   │   │   │   │   ├──
│   │   │   │   │   │   │   │   ├──
│   │   │   │   │   │   │   │   │   ├──
│   │   │   │   │   │   │   │   │   │   ├──
│   │   │   │   │   │   │   │   │   │   │   ├──
│   │   │   │   │   │   │   │   │   │   │   │   ├──
│   │   │   │   │   │   │   │   │   │   │   │   │   ├──
│   │   │   │   │   │   │   │   │   │   │   │   │   │   ├──
│   │   │   │   │   │   │   │   │   │   │   │   │   │   │   ├──
│   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   ├──

He intentado eliminar el repositorio a través de su inode ref:

[root@node repo.git/refs]# ls -latri
total 16
5551210 drwxr-xr-x. 2 git git 8192 Jun  1 21:21 heads

[root@node repo.git/refs]# find . -inum 5551210 -exec rm -rf {} \;
rm: cannot remove `./refs/heads': Directory not empty
find: `./refs/heads/': No such file or directory
find: `./refs/heads/': No such file or directory

No sé qué hacer aquí: ¿la información de inodo en el ls -latricomando parece indicar que hay 2 directorios en el directorio 'heads' que son enlaces duros al directorio heads?

Cualquier idea sobre cómo limpiar esto sería muy bienvenida: creo que he resuelto el problema de la aplicación que estaba causando, pero el problema más grande con el sistema de archivos debe resolverse.

¡Gracias!

Editar: bit de salida adicional:

sin caracteres ocultos:

[root@node repo.git/refs]# ls -latrib heads/
total 28
5551210 drwxr-xr-x. 2 git git 8192 Jun  1 21:21 .
5551210 drwxr-xr-x. 2 git git 8192 Jun  1 21:21
5551210 drwxr-xr-x. 2 git git 8192 Jun  1 21:21
5551209 drwxr-xr-x. 3 git git 4096 Jun  1 22:09 ..

pero aquí hay una salida divertida cuando estoy en el directorio de cabezas:

[root@node repo.git/refs/heads]# ls -latrib
ls: cannot access : No such file or directory
ls: cannot access : No such file or directory
total 12
      ? -?????????? ? ?   ?      ?            ?
      ? -?????????? ? ?   ?      ?            ?
5551210 drwxr-xr-x. 2 git git 8192 Jun  1 21:21 .
5551209 drwxr-xr-x. 3 git git 4096 Jun  1 22:09 ..
linux redhat nfs Viejos Noakes
fuente
Su ls -latrisalida es impar ya que el recuento de enlaces para el inodo 5551210 es impar si existen esos dos directorios adicionales. ¿Podrías intentarlo ls -latrib? ¿Cuál es el tipo de sistema de archivos subyacente?
Paul Haldane
Hola, el tipo de sistema de archivos es nfs4 - la salida con el indicador -b es exactamente igual que sin - he agregado la información que pude arriba
oldNoakes
¿Ha mirado el directorio problemático en el servidor NFS (el servidor desde el cual su VM de control de versiones está montando el sistema de archivos)? Creo que necesita ver qué piensa que está sucediendo (y era el tipo de sistema de archivos en el servidor NFS lo que estaba preguntando).
Paul Haldane
2
¿El sistema de archivos está intacto? Esos signos de interrogación en la lssalida son sospechosos para mí. ¿Has ejecutado fsck en el servidor NFS?
Lacek
3
Recomiendo hacer un fsck ... en particular, antes de ver más corrupción.
HA SALIDO - Anony-Mousse

Respuestas:

3

Primero: Git no puede ser la causa ni la solución de un problema que se manifiesta como un resultado sin sentido de ls. Deje de usar Git u otras herramientas en el sistema de archivos y desmóntelo para evitar daños.

Esto parece un sistema de archivos roto o un montaje roto. Intente desmontar y volver a montar el sistema de archivos en el cliente. Intente reiniciar completamente el cliente. Intente hacer el mismo montaje en otro cliente. Cada vez, verifique esa lssalida para ver si se vuelve normal. Esto lo ayudará a diagnosticar si el problema está en el lado del servidor NFS. Si el lsresultado sigue siendo el mismo, la investigación y reparación del sistema de archivos ( fscko lo que sea) y / o el servicio NFS (reiniciar demonios relacionados con NFS; reiniciar si nfsd está en el núcleo) debe realizarse en el lado del servidor.

ruina
fuente