IO-Fehler in rsync während der täglichen Sicherung

Question

Ich habe einen Beispiel-NAS-Server (QNAP TS-210) mit sehr eingeschränktem Linux an Bord (obwohl etwas verstärkt mit Optware/IPKG). Ich bin ein Linux-Neuling. Nachdem ich im Internet gestöbert hatte, konnte ich mein eigenes Backup-Skript schreiben, wobei ich rsync zum Synchronisieren von Dateien zwischen der NAS-Festplatte und externen USB-Laufwerken und CRON zum regelmäßigen Ausführen dieses Skripts verwendete.

Bis vor ein paar Tagen war alles in Ordnung. Die vom Backup-Skript generierten E-Mails enthielten Informationen IO error encountered -- skipping file deletionzu vielen Ressourcen (Ordnern), die gesichert wurden. Als ich dasselbe Skript über SSH ausführte, erhielt ich viele Fehlerzeilen mit dem Inhalt „ cannot send file with empty name in...“, gefolgt von „ rsync error: some files/attrs were not transferred (see previous errors)“.

100 % der Inhalte, die ich sichere, stammen von Windows (ich verwende NAS nur, um meine eigenen Computer zu sichern). Dieses System erlaubt es nicht, eine Datei mit leerem Namen zu erstellen. Dieses Problem besteht erst seit ein paar Tagen und ich habe meine Backups über mehrere Wochen (Urlaub) nicht geändert. Es muss also ein Linux-Problem (an Bord meines NAS) sein.

Die Frage ist: Was kann dazu führen, dass Dateien mit leeren Namen angezeigt werden? Wie kann ich sie loswerden (wenn ich cdden im Rsync-Bericht genannten Ordner öffne und das tue ls -ls, sehe ich nichts wie „Datei mit leerem Namen“), sodass der nächste Rsync-Durchlauf ohne solche Fehler endet. Und schließlich – wie vermeide ich in Zukunft, solche Dateien zu erhalten?

Answer 1

Ich glaube nicht, dass das die Schuld von rsync ist. Ich denke, Sie haben dies richtig als Kernel-Level-Problem markiert, da der relevante Codeflist.caus den Quellen von rsynclautet:

1729         for (errno = 0, di = readdir(d); di; errno = 0, di = readdir(d)) {
1730                 unsigned name_len;
1731                 char *dname = d_name(di);
...
1746                 if (dname[0] == '\0') {
1747                         io_error |= IOERR_GENERAL;
1748                         rprintf(FERROR_XFER,
1749                                 "cannot send file with empty name in %s\n",
1750                                 full_fname(fbuf));

Tatsächlich wurde diese Codezeile vom rsync-Entwickler hinzugefügtim August 2007speziell für diesen Fall:

If readdir() gives us an empty name, reject it.

Mit anderen Worten, readdir()selbst (die Kernelfunktion, die die Liste der Dateien in einem Verzeichnis zurückgibt) hat einen Eintrag mit einer leeren Zeichenfolge zurückgegeben. Nach den Regeln sollte das nie passieren. Zitat aus demOffene Gruppenspezifikation:

The readdir() function shall not return directory entries containing empty names.

Es klingt, als wäre es ein vorübergehendes Problem gewesen, denn als Sie lsin diesem Verzeichnis eine ausgeführt haben (was auch der Fall gewesen wäre readdir(), war es weg).

Also die Antwort auf Ihre Fragen:

1. Die Ursache scheint ein beschädigtes Dateisystem zu sein – die Ursache kann alles sein, vom Kerneltreiberfehler bis zum Hardwarefehler.Es kann auch sinnvoll sein, zu prüfen, ob auf das Verzeichnis, über das Sie rsync ausführen, über einen symbolischen Link zugegriffen wird oder ob es selbst eine Netzwerkgrenze überschreitet, wo möglicherweise Probleme auftreten.

2. So werden Sie sie los: die übliche Checkliste zur Dateisystemreparatur: fsck usw.

3. Um dies in Zukunft zu vermeiden: Ich nehme an, Sie könnten Ihrem Skript sagen, dass es im Voraus eine rekursive Auflistung erzwingen soll – aber da Sie bereits bemerkt werden (und aus dem Urlaub zurück sind), scheint es das Richtige zu sein, ein Auge darauf zu haben und zur Kasse zu gehen, wenn es erneut passiert.

Hoffe, das war hilfreich, viel Glück!