Невозможно удалить каталог Linux - бесконечная рекурсия

8

У нас есть монтирование NFS на виртуальной машине RHEL6, которая поддерживает наш сервер контроля версий - недавно одно из репозиториев сошло с ума, и вот что я нашел на сервере:

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

Когда я бегу treeпротив dir, он кажется бесконечно рекурсивным, например:

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

Я попытался удалить репозиторий с помощью его 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

Я немного растерялся, что мне здесь делать - информация inode о ls -latriкоманде, похоже, указывает на то, что в каталоге'главы 'есть 2 каталога, которые являются жесткими ссылками на каталог заголовков?

Любые идеи о том, как убрать это, были бы очень желательны - думаю, я решил проблему приложения, которую это вызывало, но большая проблема с файловой системой должна быть отсортирована.

Спасибо!

Редактировать: бит дополнительного вывода:

нет скрытых персонажей:

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

но вот забавный вывод, когда я на самом деле в головах режиссера:

[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 oldNoakes
источник
Ваш ls -latriвывод нечетный, так как счетчик ссылок для inode 5551210 нечетен, если есть эти две дополнительные директории. Не могли бы вы попробовать ls -latrib? Какой базовый тип файловой системы?
Пол Холдейн
Эй, тип файловой системы nfs4 - вывод с флагом -b такой же, как и без него - добавил, какую информацию я мог бы выше
oldNoakes
Вы смотрели на проблемный каталог на NFS-сервере (сервере, с которого виртуальная машина управления версиями монтирует файловую систему)? Я думаю, вам нужно посмотреть, что, по его мнению, происходит (и это был тип файловой системы на сервере NFS, о котором я спрашивал).
Пол Холдейн
2
Не повреждена ли файловая система? Эти знаки вопроса в lsвыводе подозрительны для меня. Вы запускаете fsck на сервере NFS?
Lacek
3
Я настоятельно рекомендую сделать fsck ... в частности, прежде чем вы увидите дальнейшую коррупцию.
ВЫЙТИ - Anony-Mousse

Ответы:

3

Первое: Git не может быть ни причиной, ни решением проблемы, которая проявляется как бессмысленный вывод ls. Прекратите использование Git или других инструментов в файловой системе и размонтируйте его, чтобы избежать вреда.

Это похоже на сломанную файловую систему или сломанное монтирование. Попробуйте размонтировать и перемонтировать файловую систему на клиенте. Попробуйте полностью перезагрузить клиент. Попробуйте выполнить такое же монтирование на другом клиенте. Каждый раз проверяйте этот lsвывод, чтобы увидеть, станет ли он нормальным. Это поможет вам диагностировать проблему на стороне сервера NFS. Если lsвыходные данные продолжают выглядеть одинаково, исследование и исправление файловой системы ( fsckили чего-либо еще) и / или службы NFS (перезапуск демонов, связанных с NFS; перезагрузка, если nfsd встроен в ядро), необходимо выполнить на стороне сервера.

ruief
источник