Signos de interrogación que se muestran en ls del directorio. Errores IO también

¿Alguien ha visto esto antes? Tengo una incursión 5 montada en mi servidor y, por cualquier motivo, comenzó a mostrar esto:

jason @ box2: / mnt / raid1 / cra $ ls -alh
ls: no se puede acceder a e6eacc985fea729b2d5bc74078632738: error de entrada / salida
ls: no se puede acceder a 257ad35ee0b12a714530c30dccf9210f: error de entrada / salida
total 0
drwxr-xr-x 5 root root 123 2009-08-19 16:33.
drwxr-xr-x 3 root root 16 14/08/2009 17:15 ..
?????????? ? ? ? ? ? 257ad35ee0b12a714530c30dccf9210f
drwxr-xr-x 3 root root 57 2009-08-19 16:58 9c89a78e93ae6738e01136db9153361b
?????????? ? ? ? ? ? e6eacc985fea729b2d5bc74078632738

Las cadenas md5 son nombres de directorio reales y no forman parte del error. Los signos de interrogación son extraños, y cualquier directorio con un signo de interrogación arroja un error io cuando intenta usar / eliminar / etc.

No pude desmontar la unidad debido a "ocupado". Reiniciar el servidor lo "solucionó" pero arrojaba algunos errores de incursión al apagarse. He configurado dos matrices raid 5 y ambas comencé a hacer esto en archivos aleatorios. Ambos usan la siguiente configuración:

mkfs.xfs -l tamaño = 128m -d cuenta = 32
mount -t xfs -o noatime, logbufs = 8

Nada demasiado elegante, pero parte de una configuración optimizada para este cuadro. No estamos particionando las unidades y eso fue sugerido como un posible problema. ¿Podría ser este el culpable?

Tuve un problema similar porque mi directorio tenía derechos de lectura (r) pero no de ejecución (x). Mi listado de directorio mostró:

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

El directorio de correo tenía establecido el bit r, pero no la x que necesita para listar o buscar y acceder. Hacer sudo chmod -R g+x mailsolucionó este problema.

Los signos de interrogación en la lssalida solo indican que no se pudo stat()ingresar al directorio. También puede verlos si tiene lsun directorio para el que tiene permiso r (ead) pero no x (búsqueda). Sin embargo, en ese caso no sería reportar error de E / S .

En su caso, parece que hay un error de disco o posiblemente corrupción del sistema de archivos. /var/log/messageso dmesges probable que revele más detalles.

Las respuestas que mencionan la lectura, pero no la ejecución o stat () son correctas. Pero hay una causa común de esto (aparte de la corrupción) que me ha mordido varias veces y que coincidiría con su pregunta con los errores de E / S muy bien. Si monta incorrectamente un sistema de archivos, el punto de montaje de ese sistema de archivos puede aparecer con signos de interrogación. Si está viendo estos en los que acaba de intentar montar un nuevo sistema de archivos, intente lo siguiente antes de preocuparse por la corrupción y fsck.

$ sudo umount /mnt/raid1/cra/257ad35ee0b12a714530c30dccf9210f
$ ls -alh /mnt/raid1/cra

Debería ver la carpeta 257ad35ee0b12a714530c30dccf9210f con permisos y atributos en lugar de signos de interrogación. Si es así, busque otras opciones para su comando de montaje o / etc / fstab. De lo contrario, tal vez sea hora de leer las otras respuestas, hacer una copia de seguridad de lo que pueda y ejecutar un fsck.

Realice una copia de seguridad tan pronto como sea humanamente posible, aunque solo sea para que si la estropea aún más mientras intenta reparar cualquier daño potencial, pueda volver al estado original menos roto. Después de realizar una copia de seguridad, puede ejecutar fsck para ver si cree que hay algún problema.

Pueden ser nombres de archivo que solo contienen caracteres que no se pueden mostrar. Intente verificar los nombres de archivo con emacs DirEd:

http://www.cs.utah.edu/dept/old/texinfo/emacs19/emacs_32.html

Teníamos un servidor con un sistema de archivos dañado (reiserfs) y generaba entradas de directorio con signos de interrogación para todos los atributos, excepto el nombre de archivo. En nuestro caso, los nombres de los archivos no se vieron afectados.

Además, el espacio libre se informaba incorrectamente. Con el uso du -sh /*solo pudimos dar cuenta de aproximadamente 30G, pero se informó que la unidad tenía más de 200G en uso.

Reiniciar el servidor con shutdown -rF nowpara forzar una comprobación del sistema de archivos no funcionó. Tuve que reiniciar en modo de usuario único y ejecutar:

fsck.reiserfs --rebuild-tree /dev/sda3

Esto casi funcionó. Pasó por unos pocos pases, luego se encerró. Tuve que reinstalar el sistema operativo.

¡Mantenga sus copias de seguridad!

También he visto esto cuando ejecuto autofs, pero los autofs no pueden montar el directorio. Entonces, para descubrir por qué no podía montar el directorio, desactivé los autofs e intenté montar el directorio manualmente (esto también me permitió eliminar el directorio). Intenté montar el directorio manualmente y descubrí que había un error de permisos. Después de arreglar eso, el directorio volvió a la normalidad nuevamente.

Tenga cuidado con otros procesos en ejecución en el servidor, por ejemplo 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

Genera archivos temporales que se crean y eliminan rápidamente, lo que provocará errores si intenta llamar a otros comandos simples de administración de archivos como rm , mv , etc.

Solo para dar una perspectiva diferente: tuve esto cuando estaba generando programáticamente directorios a partir de una lista de directorios en un archivo (en ruby).

Por supuesto, la línea del archivo apareció como una cadena con un \ n en el extremo, que se veía bien y parecía funcionar. Sin embargo, cuando comencé a crear directorios en lugar de ser masticado, terminé creando dos de cada directorio: /whatiwantedy /whatiwanted?.

A veces veo esto como un error transitorio cuando un servidor NFS está muy sobrecargado.

El OP preguntó por RAID, pero varias respuestas mencionan NFS, y de hecho esa fue la búsqueda que me trajo aquí.