Impossible de supprimer le répertoire Linux - récursion infinie


8

Nous avons un montage NFS sur une machine virtuelle RHEL6 qui prend en charge notre serveur de contrôle de version - récemment, l'un des référentiels est devenu un peu fou et voici ce que j'ai trouvé sur le serveur:

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 ..

Lorsque je cours treecontre le répertoire, il semble être infiniment récursif - par exemple:

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

J'ai tenté de supprimer le référentiel via sa référence d'inode:

[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

Je ne sais pas trop quoi faire ici - les informations d'inode sur la ls -latricommande semblent indiquer qu'il y a 2 répertoires dans le répertoire «têtes» qui sont des liens physiques vers le répertoire têtes?

Toutes les idées sur la façon de nettoyer cela seraient les bienvenues - pensez que j'ai résolu le problème d'application qu'il causait, mais le plus gros problème avec le système de fichiers doit être trié.

Je vous remercie!

Edit: bit de sortie supplémentaire:

pas de caractères cachés:

[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 ..

mais voici une sortie amusante quand je suis en fait dans le répertoire des têtes:

[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 ..

Votre ls -latrisortie est étrange car le nombre de liens pour l'inode 5551210 est impair s'il y a ces deux répertoires supplémentaires. Pourriez-vous essayer ls -latrib? Quel est le type de système de fichiers sous-jacent?
Paul Haldane

Hé, le type de système de fichiers est nfs4 - la sortie avec l'indicateur -b est exactement la même que sans - j'ai ajouté les informations que j'ai pu ci
oldNoakes

Avez-vous regardé le répertoire problématique sur le serveur NFS (le serveur à partir duquel votre machine virtuelle de contrôle de version monte le système de fichiers)? Je pense que vous devez voir ce qui se passe (et c'est le type de système de fichiers sur le serveur NFS que je demandais).
Paul Haldane

2
Le système de fichiers est-il intact? Ces points d'interrogation dans la lssortie me sont suspects. Avez-vous exécuté fsck sur le serveur NFS?
Lacek

3
Je recommande fortement de faire un fsck ... en particulier, avant de voir plus de corruption.
A QUIT - Anony-Mousse

Réponses:


3

Premièrement: Git ne peut être ni la cause ni la solution d'un problème qui se manifeste par une sortie absurde ls. Arrêtez d'utiliser Git ou d'autres outils sur le système de fichiers et démontez-le pour éviter tout dommage.

Cela ressemble à un système de fichiers cassé ou à un support cassé. Essayez de démonter et de remonter le système de fichiers sur le client. Essayez de redémarrer complètement le client. Essayez de faire le même montage sur un autre client. À chaque fois, vérifiez cette lssortie pour voir si elle devient normale. Cela vous aidera à diagnostiquer si le problème est du côté serveur NFS. Si la lssortie continue de ressembler, une enquête et une réparation du système de fichiers ( fsckou autre) et / ou du service NFS (redémarrage des démons liés à NFS; redémarrage si nfsd est dans le noyau) doivent avoir lieu côté serveur.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.