Impossibile eliminare la directory Linux - ricorsione infinita


8

Abbiamo un mount NFS su una VM RHEL6 che supporta il nostro server di controllo versione - recentemente, uno dei repository è diventato un po 'pazzo e questo è quello che ho trovato sul server:

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

Quando corro treecontro il dir, sembra essere infinitamente ricorsivo - ad esempio:

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

Ho tentato di eliminare il repository tramite il suo 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

Sono un po 'perplesso che cosa fare qui: le informazioni sull'inode sul ls -latricomando sembrano indicare che ci sono 2 directory nella directory' heads 'che sono collegamenti diretti alla directory heads?

Qualsiasi idea su come ripulirlo sarebbe molto gradita: penso di aver risolto il problema dell'applicazione che stava causando, ma il problema più grande con il filesystem deve essere risolto.

Grazie!

Modifica: bit di output aggiuntivo:

nessun personaggio nascosto:

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

ma ecco un output divertente quando sono effettivamente nella direttrice head:

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

L' ls -latrioutput è dispari poiché il conteggio dei collegamenti per l'inode 5551210 è dispari se ci sono queste due directory extra. Potresti provare ls -latrib? Qual è il tipo di filesystem sottostante?
Paul Haldane,

Ehi, il tipo di file system è nfs4 - l'output con il flag -b è esattamente lo stesso di senza - ho aggiunto quali informazioni ho potuto sopra
oldNoakes

Hai esaminato la directory problematica sul server NFS (il server da cui la tua VM di controllo versione sta montando il filesystem)? Penso che tu debba vedere cosa pensa stia accadendo (ed era il tipo di filesystem sul server NFS di cui mi chiedevo).
Paul Haldane,

2
Il file system è intatto? Quei punti interrogativi lsnell'output sono sospetti per me. Hai eseguito fsck sul server NFS?
Lacek,

3
Consiglio vivamente di fare un fsck ... in particolare, prima di vedere qualsiasi ulteriore corruzione.
Ha QUIT - Anony-Mousse il

Risposte:


3

Primo: Git non può essere né la causa né la soluzione di un problema che si manifesta come output privo di senso da ls. Smetti di usare Git o altri strumenti sul filesystem e smontalo per evitare danni.

Sembra un filesystem rotto o un mount rotto. Prova a smontare e rimontare il filesystem sul client. Prova a riavviare completamente il client. Prova a fare lo stesso mount su un altro client. Ogni volta, controlla lsquell'uscita per vedere se diventa normale. Questo ti aiuterà a diagnosticare se il problema è sul lato server NFS. Se l' lsoutput continua ad avere lo stesso aspetto, l'indagine e la riparazione del filesystem ( fscko di qualsiasi altra cosa) e / o del servizio NFS (riavvio dei daemon relativi a NFS; riavvio se nfsd è nel kernel) deve avvenire sul lato server.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.