Points d'interrogation affichés dans ls du répertoire. IO erreurs aussi
Quelqu'un a-t-il déjà vu cela avant? J'ai un raid 5 monté sur mon serveur et pour une raison quelconque, il a commencé à montrer ceci:
jason @ box2:/mnt/raid1/cra $ ls -alh ls: impossible d'accéder à e6eacc985fea729b2d5bc74078632738: Erreur d'entrée/sortie ls: impossible d'accéder à 257ad35ee0b12a714530c30dccf9210f: Input/output .____.] total 0 racine racine drwxr-xr-x 5 123 2009-08-19 16:33. racine racine drwxr-xr-x 3 16 2009-08-14 17: 15 .. ?????????? ? ? ? ? ? 257ad35ee0b12a714530c30dccf9210f Racine racine drwxr-xr-x 3 57 2009-08-19 16:58 9c89a78e93ae6738e01136db9153361b ?????????? ? ? ? ? ? e6eacc985fea729b2d5bc74078632738
Les chaînes md5 sont des noms de répertoire réels et ne font pas partie de l'erreur. Les points d'interrogation sont impairs, et tout répertoire avec un point d'interrogation génère une erreur io lorsque vous essayez de l'utiliser/supprimer/etc.
Je n'ai pas pu démonter le disque en raison de "occupé". Le redémarrage du serveur l'a "corrigé", mais il provoquait des erreurs de raid à l'arrêt. J'ai configuré deux tableaux RAID 5 et les deux ont commencé à le faire sur des fichiers aléatoires. Les deux utilisent la configuration suivante:
mkfs.xfs -l size = 128m -d agcount = 32 mount -t xfs -o noatime, logbufs = 8
Rien d'extraordinaire, mais fait partie d'une config optimisée pour cette box. Nous ne partitionnons pas les disques et cela a été suggéré comme un problème possible. Cela pourrait-il être le coupable?
J'ai eu un problème similaire car mon répertoire avait lu (r) mais pas exécuté (x) les droits. Ma liste d'annuaire a montré:
myname@srv:/home$ ls -l service/mail/
ls: cannot access service/mail/001_SERVICE INBOX: Permission denied
total 0
-????????? ? ? ? ? ? 001_SERVICE INBOX
d????????? ? ? ? ? ? 01_CURRENT SERVICE
Le répertoire de messagerie avait le bit r défini, mais pas le x dont vous avez besoin pour lister ou rechercher et accéder. Faire Sudo chmod -R g+x mail a résolu ce problème.
Les points d'interrogation dans la sortie ls indiquent simplement qu'il n'a pas pu stat() l'entrée de répertoire. Vous pouvez également les voir si vous ls un répertoire pour lequel vous disposez de l'autorisation r(ead) mais pas x (recherche). Cependant, dans ce cas, il ne signalera pas - erreur d'E/S.
Dans votre cas, il semble qu'il y ait une erreur de disque ou peut-être une corruption du système de fichiers. /var/log/messages ou dmesg est susceptible de révéler de plus amples détails.
Les réponses mentionnant le read, mais pas execute ou stat () sont correctes. Mais il existe une cause courante (autre que la corruption) qui m'a mordu plusieurs fois et qui correspond bien à votre question avec les erreurs IO. Si vous montez un système de fichiers de manière incorrecte, le point de montage de ce système de fichiers peut apparaître avec des points d'interrogation. Si vous les voyez là où vous venez d'essayer de monter un nouveau système de fichiers, essayez ce qui suit avant de vous soucier de la corruption et de fsck.
$ Sudo umount /mnt/raid1/cra/257ad35ee0b12a714530c30dccf9210f
$ ls -alh /mnt/raid1/cra
Vous devriez voir le dossier 257ad35ee0b12a714530c30dccf9210f avec des autorisations et des attributs plutôt que des points d'interrogation. Si c'est le cas, recherchez d'autres options pour votre commande de montage ou votre fichier/etc/fstab. Sinon, il est peut-être temps de lire les autres réponses, de sauvegarder ce que vous pouvez et d'exécuter un fsck.
Faites une sauvegarde dès que possible humainement, ne serait-ce que pour que si vous la gâchez davantage tout en essayant de réparer tout dommage potentiel, vous pouvez revenir à l'état d'origine le moins cassé. Après la sauvegarde, vous pouvez exécuter fsck pour voir s'il pense qu'il y a des problèmes.
Les noms de fichiers peuvent contenir uniquement des caractères non affichables. Essayez de vérifier les noms de fichiers avec emacs DirEd:
http://www.cs.utah.edu/dept/old/texinfo/emacs19/emacs_32.html
Nous avions un serveur avec un système de fichiers corrompu (reiserfs) et il générait des entrées de répertoire avec des points d'interrogation pour tous les attributs sauf le nom de fichier. Dans notre cas, les noms de fichiers n'ont pas été affectés.
En outre, l'espace libre était signalé de manière incorrecte. En utilisant du -sh /* nous ne pouvions représenter que 30 G environ, mais le disque était signalé comme étant supérieur à 200 G en cours d'utilisation.
Redémarrage du serveur avec shutdown -rF now pour forcer une vérification du système de fichiers n'a pas fonctionné. J'ai dû redémarrer en mode mono-utilisateur et exécuter:
fsck.reiserfs --rebuild-tree /dev/sda3
Cela presque a fonctionné. Il a traversé quelques passes, puis s'est enfermé. J'ai dû réinstaller le système d'exploitation.
Maintenez vos sauvegardes!
J'ai également vu cela lors de l'exécution d'autofs, mais les autofs ne peuvent pas monter le répertoire. Alors, pour comprendre pourquoi il ne pouvait pas monter le répertoire, j'ai désactivé autofs et essayé de monter le répertoire manuellement (cela m'a également permis de supprimer le répertoire). J'ai essayé de monter le répertoire manuellement et j'ai constaté qu'il y avait une erreur d'autorisation. Après avoir corrigé cela, le répertoire est revenu à la normale.
Attention aux autres processus en cours d'exécution sur le serveur par exemple rsync
[root@server upload]# ls -la
ls: cannot access .3bfb3dc5-cb55-435f-8e23-2afcab2c6873_image4993891600240007749.jpg.bV6VTV: No such file or directory
total 194496
drwxr-x--- 2 gx Apache 1382 Jan 11 10:36 .
drwxr-x--- 3 gx Apache 3 Jan 11 10:29 ..
-rw-r--r-- 1 gx Apache 94850 Dec 10 2015 37d355b9-210d-45df-8061-968ea5cb9f31_mob.jpg
...
-rw-r--r-- 1 gx Apache 10864 Jul 24 2015 3bfb23bf-8ff5-4603-aa57-9b23ca498e2c_internet.png
-rw-r--r-- 1 gx Apache 10864 Jul 24 2015 .3bfb23bf-8ff5-4603-aa57-9b23ca498e2c_internet.png.nHmIPk
-????????? ? ? ? ? ? .3bfb3dc5-cb65-435f-8e23-2agcab2c6873_image4993891600240007749.jpg.bV6VTV
Il génère des fichiers temporaires qui sont créés et déposés rapidement, ce qui provoquera des erreurs si vous essayez d'appeler d'autres commandes de gestion de fichiers simples comme rm, mv etc.
Je vois parfois cela comme une erreur transitoire lorsqu'un serveur NFS est fortement surchargé.
L'OP a posé des questions sur RAID, mais plusieurs réponses mentionnent NFS, et en fait c'est la recherche qui m'a amené ici.
Juste pour donner une perspective différente - je l'avais quand je générais par programme des répertoires à partir d'une liste de répertoires dans un fichier (en Ruby).
Bien sûr, la ligne du fichier est apparue sous la forme d'une chaîne avec un\n à la fin - qui avait l'air bien et semblait fonctionner. Cependant, comme j'ai commencé à créer des répertoires plutôt que d'être chompé, il a fini par créer deux de chaque répertoire: /whatiwanted et /whatiwanted?.