Punti interrogativi visualizzati in ls della directory. Anche errori IO

Qualcuno l'ha mai visto prima? Ho un raid 5 montato sul mio server e per qualsiasi motivo ha iniziato a mostrare questo:

jason @ box2: / mnt / raid1 / cra $ ls -alh
ls: impossibile accedere a e6eacc985fea729b2d5bc74078632738: errore di input / output
ls: impossibile accedere a 257ad35ee0b12a714530c30dccf9210f: errore di input / output
totale 0
drwxr-xr-x 5 root root 123 2009-08-19 16:33.
drwxr-xr-x 3 root root 16 2009-08-14 17:15 ..
?????????? ? ? ? ? ? 257ad35ee0b12a714530c30dccf9210f
drwxr-xr-x 3 root root 57 2009-08-19 16:58 9c89a78e93ae6738e01136db9153361b
?????????? ? ? ? ? ? e6eacc985fea729b2d5bc74078632738

Le stringhe md5 sono nomi di directory effettivi e non fanno parte dell'errore. I punti interrogativi sono dispari e qualsiasi directory con un punto interrogativo genera un errore io quando si tenta di utilizzarlo / eliminarlo / ecc.

Non è stato possibile smontare l'unità a causa di "occupato". Il riavvio del server lo ha "riparato" ma stava causando alcuni errori di raid allo spegnimento. Ho configurato due array raid 5 ed entrambi ho iniziato a farlo su file casuali. Entrambi utilizzano la seguente configurazione:

mkfs.xfs -l size = 128m -d agcount = 32
mount -t xfs -o noatime, logbufs = 8

Niente di speciale, ma parte di una configurazione ottimizzata per questa scatola. Non stiamo partizionando le unità e questo è stato suggerito come possibile problema. Potrebbe essere questo il colpevole?

Ho avuto un problema simile perché la mia directory aveva letto (r) ma non aveva eseguito i diritti (x). Il mio elenco di directory ha mostrato:

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

La directory di posta aveva il bit r impostato, ma non la x di cui hai bisogno per elencare o cercare e accedere. Fare sudo chmod -R g+x mailrisolto questo problema.

I punti interrogativi lsnell'output indicano semplicemente che non è stato possibile inserire stat()la directory. Puoi anche vedere quelli se hai lsuna directory per la quale hai l'autorizzazione r (ead) ma non x (cerca). Tuttavia in questo caso non sarebbe segnalare errore di I / O .

Nel tuo caso sembra che ci sia un errore del disco o possibilmente la corruzione del file system. /var/log/messageso dmesgrischia di rivelare ulteriori dettagli.

Le risposte che menzionano read, ma non execute o stat () sono corrette. Ma c'è una causa comune di questo (oltre alla corruzione) che mi ha morso alcune volte e avrebbe abbinato bene la tua domanda agli errori IO. Se si monta erroneamente un filesystem, il punto di mount di quel filesystem può apparire con punti interrogativi. Se vedi questi dove hai appena provato a montare un nuovo filesystem, prova quanto segue prima di preoccuparti di corruzione e fsck.

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

Dovresti vedere la cartella 257ad35ee0b12a714530c30dccf9210f con autorizzazioni e attributi anziché punti interrogativi. In tal caso, cercare altre opzioni per il comando mount o il file / etc / fstab. In caso contrario, forse è il momento di leggere le altre risposte, eseguire il backup di ciò che è possibile ed eseguire un fsck.

Effettua un backup non appena umanamente possibile, se non altro in modo che, se lo rovini ulteriormente mentre provi a riparare qualsiasi danno potenziale, puoi tornare allo stato originale meno danneggiato. Dopo il backup, potresti eseguire fsck per vedere se pensa che ci siano problemi.

I nomi dei file possono contenere solo caratteri non visualizzabili. Prova a controllare i nomi dei file con emacs DirEd:

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

Avevamo un server con un filesystem corrotto (reiserfs) e generava voci di directory con punti interrogativi per tutti gli attributi tranne il nome file. Nel nostro caso, i nomi dei file non sono stati interessati.

Inoltre, lo spazio libero veniva segnalato in modo errato. Usando du -sh /*abbiamo potuto rappresentare solo circa 30 G, ma l'unità è stata segnalata come oltre 200 G in uso.

Il riavvio del server con shutdown -rF nowper forzare un controllo del file system non ha funzionato. Ho dovuto riavviare in modalità utente singolo ed eseguire:

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

Questo ha quasi funzionato. Superò alcuni passaggi, poi si chiuse. Ho dovuto reinstallare il sistema operativo.

Mantieni i tuoi backup!

Ho visto anche questo quando eseguo autofs ma autofs non può montare la directory. Quindi, per capire perché non è stato possibile montare la directory ho disabilitato autofs e ho provato a montare la directory manualmente (questo mi ha anche permesso di eliminare la directory). Ho provato a montare manualmente la directory e ho scoperto che c'era un errore di permessi. Dopo aver risolto ciò, la directory è tornata alla normalità.

Fai attenzione agli altri processi in esecuzione sul server, ad esempio 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 file temporanei che vengono creati e rilasciati rapidamente, il che causerà errori se si tenta di chiamare altri semplici comandi di gestione dei file come rm , mv ecc.

Giusto per dare una prospettiva diversa - l'ho avuto quando stavo generando programmaticamente directory da un elenco di directory in un file (in ruby).

Ovviamente la linea dal file è arrivata come una stringa con un \ n alla fine - che sembrava buono e sembrava funzionare. Tuttavia, quando ho iniziato a creare directory piuttosto che essere chomp, ha finito per creare due di ogni directory: /whatiwantede /whatiwanted?.

A volte vedo questo come un errore temporaneo quando un server NFS è fortemente sovraccarico.

L'OP ha chiesto di RAID ma diverse risposte menzionano NFS, e in effetti è stata la ricerca che mi ha portato qui.