Fragezeichen werden in ls des Verzeichnisses angezeigt. IO-Fehler auch

Hat das schon mal jemand gesehen? Ich habe einen RAID 5 auf meinem Server gemountet und aus welchem ​​Grund auch immer wurde dies angezeigt:

jason @ box2: / mnt / raid1 / cra $ ls -alh
ls: Kein Zugriff auf e6eacc985fea729b2d5bc74078632738: Eingabe- / Ausgabefehler
ls: Kein Zugriff auf 257ad35ee0b12a714530c30dccf9210f: Eingabe- / Ausgabefehler
insgesamt 0
drwxr-xr-x 5 root root 123 19.08.2009 16:33.
drwxr-xr-x 3 root root 16 14.08.2009 17:15 ..
?????????? ? ? ? ? ? 257ad35ee0b12a714530c30dccf9210f
drwxr-xr-x 3 root root 57 19.08.2009 16:58 9c89a78e93ae6738e01136db9153361b
?????????? ? ? ? ? ? e6eacc985fea729b2d5bc74078632738

Die md5-Zeichenfolgen sind tatsächliche Verzeichnisnamen und nicht Teil des Fehlers. Die Fragezeichen sind ungerade und jedes Verzeichnis mit einem Fragezeichen gibt einen io-Fehler aus, wenn Sie versuchen, / delete / etc zu verwenden.

Ich konnte das Laufwerk aufgrund von "beschäftigt" nicht ummounten. Durch einen Neustart des Servers wurde das Problem behoben, aber beim Herunterfahren traten RAID-Fehler auf. Ich habe zwei RAID 5-Arrays konfiguriert und beide haben damit begonnen, zufällige Dateien zu bearbeiten. Beide verwenden die folgende Konfiguration:

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

Nichts besonderes, aber Teil einer optimierten Konfiguration für diese Box. Wir partitionieren die Laufwerke nicht und dies wurde als mögliches Problem vorgeschlagen. Könnte dies der Schuldige sein?

Ich hatte ein ähnliches Problem, weil mein Verzeichnis die Rechte zum Lesen (r) aber nicht zum Ausführen (x) hatte. Meine Verzeichnisliste zeigte:

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

Das Mail-Verzeichnis hatte das r-Bit gesetzt, aber nicht das x, das Sie für die Auflistung oder Suche und den Zugriff benötigen. Dadurch wurde sudo chmod -R g+x maildieses Problem gelöst.

Die Fragezeichen in der lsAusgabe zeigen nur an, dass stat()der Verzeichniseintrag nicht möglich war . Sie können diese auch sehen, wenn Sie lsein Verzeichnis haben, für das Sie die Berechtigung r (ead), aber nicht x (search) haben. In diesem Fall wird jedoch kein E / A-Fehler gemeldet .

In Ihrem Fall liegt anscheinend ein Festplattenfehler oder möglicherweise eine Beschädigung des Dateisystems vor. /var/log/messagesoder dmesgwird wahrscheinlich weitere Details offenbaren.

Die Antworten, die das Lesen, aber nicht Ausführen oder stat () erwähnen, sind korrekt. Aber es gibt eine häufige Ursache (außer Korruption), die mich ein paar Mal gebissen hat und Ihre Frage mit den E / A-Fehlern in Einklang bringt. Wenn Sie ein Dateisystem nicht ordnungsgemäß bereitstellen, wird der Bereitstellungspunkt dieses Dateisystems möglicherweise mit Fragezeichen angezeigt. Wenn Sie diese sehen, bei denen Sie gerade versucht haben, ein neues Dateisystem zu mounten, versuchen Sie Folgendes, bevor Sie sich über Korruption und fsck Gedanken machen.

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

Sie sollten den Ordner 257ad35ee0b12a714530c30dccf9210f mit Berechtigungen und Attributen anstelle von Fragezeichen sehen. Wenn ja, suchen Sie nach anderen Optionen für Ihren Mount-Befehl oder die Datei / etc / fstab. Wenn nicht, ist es vielleicht an der Zeit, die anderen Antworten zu lesen, das zu sichern, was Sie können, und eine fsck auszuführen.

Erstellen Sie so schnell wie möglich eine Sicherungskopie, und sei es nur so, dass Sie in den ursprünglichen, weniger beschädigten Zustand zurückkehren können, wenn Sie bei dem Versuch, potenzielle Schäden zu beheben, weitere Fehler machen. Nach dem Sichern können Sie fsck ausführen, um festzustellen, ob Probleme vorliegen.

Möglicherweise enthalten Dateinamen nur nicht darstellbare Zeichen. Versuchen Sie, Dateinamen mit emacs DirEd zu überprüfen:

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

Wir hatten einen Server mit einem beschädigten Dateisystem (reiserfs) und er erzeugte Verzeichniseinträge mit Fragezeichen für alle Attribute außer dem Dateinamen. In unserem Fall waren die Dateinamen nicht betroffen.

Außerdem wurde der freie Speicherplatz falsch gemeldet. Unter Verwendung von du -sh /*konnten wir nur ungefähr 30 G erklären, aber das Laufwerk wurde als über 200 G im Gebrauch gemeldet.

Ein Neustart des Servers mit shutdown -rF now, um eine Dateisystemprüfung zu erzwingen, funktionierte nicht. Ich musste im Einzelbenutzermodus neu starten und Folgendes ausführen:

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

Das hat fast funktioniert. Es kam durch ein paar Pässe, dann eingesperrt. Musste das Betriebssystem neu installieren.

Pflegen Sie Ihre Backups!

Ich habe dies auch beim Ausführen von autofs gesehen, aber autofs können das Verzeichnis nicht mounten. Um herauszufinden, warum das Verzeichnis nicht gemountet werden konnte, deaktivierte ich autofs und versuchte, das Verzeichnis manuell zu mounten (dies erlaubte mir auch, das Verzeichnis zu löschen). Ich habe versucht, das Verzeichnis manuell einzuhängen, und festgestellt, dass ein Berechtigungsfehler aufgetreten ist. Nachdem dies behoben wurde, kehrte das Verzeichnis wieder in den normalen Zustand zurück.

Achten Sie auf andere laufende Prozesse auf dem Server, z. B. 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

Es generiert temporäre Dateien, die schnell erstellt und gelöscht werden. Dies führt zu Fehlern, wenn Sie versuchen, andere einfache Dateiverwaltungsbefehle wie rm , mv usw. aufzurufen .

Nur um eine andere Perspektive zu haben - das hatte ich, als ich programmgesteuert Verzeichnisse aus einer Liste von Verzeichnissen in einer Datei (in Ruby) generierte.

Natürlich kam die Zeile aus der Datei als Zeichenfolge mit einem \ n am Ende durch - was gut aussah und zu funktionieren schien. Als ich jedoch anfing, Verzeichnisse zu erstellen, anstatt gecomped zu werden, wurden zwei Verzeichnisse erstellt: /whatiwantedund /whatiwanted?.

Ich sehe dies manchmal als vorübergehenden Fehler, wenn ein NFS-Server stark überlastet ist.

Das OP fragte nach RAID, aber in mehreren Antworten wurde NFS erwähnt, und genau das war die Suche, die mich hierher geführt hat.