Warum kann rsync keine Dateien von /sys in Linux kopieren?

Rsync hat einen Code, der speziell prüft, ob eine Datei während des Lesens abgeschnitten wird, und diesen Fehler ausgibt – ENODATA . Ich weiß nicht warum die Dateien in /sys haben dieses Verhalten, aber da es sich nicht um echte Dateien handelt, ist es wohl nicht allzu überraschend. Es scheint keine Möglichkeit zu geben, rsync anzuweisen, diese spezielle Prüfung zu überspringen.

Ich denke, Sie sind wahrscheinlich besser dran, wenn Sie /sys nicht rsyncen und die Verwendung spezifischer Skripte, um die gewünschten Informationen herauszupicken (wie die Adresse der Netzwerkkarte).

Zuerst /sys ist ein Pseudo-Dateisystem . Wenn Sie sich /proc/filesystems ansehen Sie werden eine Liste registrierter Dateisysteme finden, von denen einige nodev haben vor. Dies weist darauf hin, dass es sich um Pseudo-Dateisysteme handelt . Das bedeutet, dass sie auf einem laufenden Kernel als RAM-basiertes Dateisystem existieren. Außerdem benötigen sie kein Blockgerät.

$ cat /proc/filesystems
nodev   sysfs
nodev   rootfs
nodev   bdev
...

Beim Booten hängt der Kernel dieses System ein und aktualisiert Einträge, wenn es geeignet ist. Z.B. wenn neue Hardware während des Bootens oder durch udev gefunden wird .

In /etc/mtab Sie finden das Reittier normalerweise wie folgt:

sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0

Eine nette Abhandlung zu diesem Thema finden Sie in Patric Mochel's – The sysfs Filesystem.

Statistik der /sys-Dateien

Wenn Sie in ein Verzeichnis unter /sys gehen und mache einen ls -l Sie werden feststellen, dass alle Dateien eine Größe haben. Typischerweise 4096 Byte. Dies wird von sysfs gemeldet .

:/sys/devices/pci0000:00/0000:00:19.0/net/eth2$ ls -l
-r--r--r-- 1 root root 4096 Apr 24 20:09 addr_assign_type
-r--r--r-- 1 root root 4096 Apr 24 20:09 address
-r--r--r-- 1 root root 4096 Apr 24 20:09 addr_len
...

Außerdem können Sie eine stat machen auf einer Datei und beachten Sie ein weiteres besonderes Merkmal; es belegt 0 Blöcke. Auch der Inode von root (stat /sys) ist 1. /stat/fs hat typischerweise Inode 2. etc.

rsync vs. cp

Die einfachste Erklärung für rsync-Fehler beim Synchronisieren von Pseudodateien ist vielleicht ein Beispiel.

Angenommen, wir haben eine Datei namens address das sind 18 byte. Ein ls oder stat der Datei meldet 4096 Bytes.

rsync

1. Öffnet Dateideskriptor, fd.
2. Verwendet fstat(fd), um Informationen wie die Größe zu erhalten.
3. Machen Sie sich auf den Weg, um Größenbytes zu lesen, z. B. 4096. Das wäre Zeile 253 des von @mattdm verknüpften Codes. read_size == 4096
   1. Fragen; gelesen:4096 Bytes.
   2. Ein kurzer String wird gelesen, z. B. 18 Bytes. nread == 18
   3. read_size = read_size - nread (4096 - 18 = 4078)
   4. Fragen; gelesen:4078 Byte
   5. 0 gelesene Bytes (beim ersten Lesen wurden alle Bytes in der Datei verbraucht).
   6. nread == 0 , Zeile 255
   7. 4096 kann nicht gelesen werden Byte. Puffer auf Null setzen.
   8. Fehler ENODATA setzen .
   9. Zurück.
4. Fehler melden.
5. Wiederholen. (Über Schleife).
6. Fehlgeschlagen.
7. Fehler melden.
8. FEIN.

Während dieses Vorgangs liest es tatsächlich die gesamte Datei. Aber ohne verfügbare Größe kann es das Ergebnis nicht validieren – daher ist ein Scheitern nur eine Option.

cp

1. Öffnet Dateideskriptor, fd.
2. Verwendet fstat(fd), um Informationen wie st_size zu erhalten (verwendet auch lstat und stat).

3. Überprüfen Sie, ob die Datei wahrscheinlich spärlich ist. Das heißt, die Datei hat Löcher etc.

   copy.c:1010
   /* Use a heuristic to determine whether SRC_NAME contains any sparse
    * blocks.  If the file has fewer blocks than would normally be
    * needed for a file of its size, then at least one of the blocks in
    * the file is a hole.  */
   sparse_src = is_probably_sparse (&src_open_sb);
   

   Als stat meldet, dass die Datei null Blöcke enthält, wird sie als spärlich kategorisiert.

4. Versucht, die Datei per Extent-Kopie zu lesen (eine effizientere Art, normal zu kopieren Sparse-Dateien) und schlägt fehl.

5. Kopieren durch Sparse-Kopie.
   1. Beginnt mit der maximalen Lesegröße von MAXINT.
      Normalerweise18446744073709551615 Bytes auf einem 32-Bit-System.
   2. Fragen; 4096 Byte lesen. (Puffergröße, die im Speicher von Statistikinformationen zugewiesen wird.)
   3. Ein kurzer String wird gelesen, z. B. 18 Bytes.
   4. Überprüfen Sie, ob ein Loch benötigt wird, nein.
   5. Puffer zum Ziel schreiben.
   6. Subtrahieren Sie 18 von der maximalen Lesegröße.
   7. Fragen; 4096 Bytes lesen.
   8. 0 Byte, da alle beim ersten Lesen verbraucht wurden.
   9. Rückgabeerfolg.
6. Alles in Ordnung. Flags für Datei aktualisieren.
7. FEIN.

Könnte verwandt sein, aber erweiterte Attributaufrufe schlagen bei sysfs fehl:

[[email protected] eth0]# lsattr-Adresse

lsattr:Unpassendes ioctl für Gerät beim Lesen von Flags auf Adresse

[[email protected] eth0]#

Wenn ich mir meine Strace ansehe, sieht es so aus, als würde rsync standardmäßig versuchen, erweiterte Attribute einzuziehen:

22964 <... getxattr resumed> , 0x7fff42845110, 132) =-1 ENODATA (Keine Daten verfügbar)

Ich habe versucht, ein Flag zu finden, um rsync zu geben, um zu sehen, ob das Überspringen erweiterter Attribute das Problem löst, konnte aber nichts finden (--xattrs schaltet sie ein am Ziel).