Pourquoi rsync ne parvient-il pas à copier les fichiers de /sys sous Linux ?

Rsync a un code qui vérifie spécifiquement si un fichier est tronqué pendant la lecture et donne cette erreur — ENODATA . Je ne sais pas pourquoi les fichiers en /sys ont ce comportement, mais comme ce ne sont pas de vrais fichiers, je suppose que ce n'est pas trop surprenant. Il ne semble pas y avoir de moyen de dire à rsync d'ignorer cette vérification particulière.

Je pense que vous feriez probablement mieux de ne pas rsynchroniser /sys et en utilisant des scripts spécifiques pour sélectionner les informations particulières que vous souhaitez (comme l'adresse de la carte réseau).

Tout d'abord /sys est un pseudo système de fichiers . Si vous regardez /proc/filesystems vous trouverez une liste des systèmes de fichiers enregistrés où un bon nombre a nodev devant. Cela indique qu'il s'agit de pseudo systèmes de fichiers . Cela signifie qu'ils existent sur un noyau en cours d'exécution en tant que système de fichiers basé sur la RAM. De plus, ils ne nécessitent pas de périphérique de blocage.

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

Au démarrage, le noyau monte ce système et met à jour les entrées le cas échéant. Par exemple. lorsqu'un nouveau matériel est trouvé au démarrage ou par udev .

En /etc/mtab vous trouvez généralement la monture en :

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

Pour un bel article sur le sujet, lisezPatric Mochel's - The sysfs Filesystem.

statistique des fichiers /sys

Si vous allez dans un répertoire sous /sys et faites un ls -l vous remarquerez que tous les fichiers ont une taille. Typiquement 4096 octets. Ceci est signalé par sysfs .

:/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
...

De plus, vous pouvez faire un stat sur un fichier et notez une autre caractéristique distincte ; il occupe 0 blocs. L'inode de la racine (stat /sys) est également 1. /stat/fs a généralement l'inode 2. etc.

rsync contre cp

L'explication la plus simple de l'échec de rsync lors de la synchronisation de pseudo-fichiers est peut-être un exemple.

Disons que nous avons un fichier nommé address c'est 18 octets. Un ls ou stat du fichier rapporte 4096 octets.

rsync

1. Ouvre le descripteur de fichier, fd.
2. Utilise fstat(fd) pour obtenir des informations telles que la taille.
3. Envisagez de lire la taille des octets, c'est-à-dire 4096. Ce serait la ligne 253 du code lié par @mattdm. read_size == 4096
   1. Demandez ; lecture :4 096 octets.
   2. Une chaîne courte est lue, c'est-à-dire 18 octets. nread == 18
   3. read_size = read_size - nread (4096 - 18 = 4078)
   4. Demandez ; lu :4 078 octets
   5. 0 octet lu (la première lecture a consommé tous les octets du fichier).
   6. nread == 0 , ligne 255
   7. Impossible de lire 4096 octets. Mettre à zéro le tampon.
   8. Définir l'erreur ENODATA .
   9. Retour.
4. Signaler une erreur.
5. Réessayez. (boucle ci-dessus).
6. Échec.
7. Signaler une erreur.
8. BIEN.

Au cours de ce processus, il lit en fait l'intégralité du fichier. Mais sans taille disponible, il ne peut pas valider le résultat - l'échec est donc la seule option.

cp

1. Ouvre le descripteur de fichier, fd.
2. Utilise fstat(fd) pour obtenir des informations telles que st_size (utilise également lstat et stat).

3. Vérifiez si le fichier est susceptible d'être clairsemé. C'est-à-dire que le fichier a des trous, 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);
   

   Comme stat rapporte que le fichier n'a aucun bloc, il est classé comme sparse.

4. Essaie de lire le fichier par extent-copy (un moyen plus efficace de copier normal fichiers fragmentés) et échoue.

5. Copier par copie fragmentée.
   1. Commence avec une taille de lecture maximale de MAXINT.
      Typiquement18446744073709551615 octets sur un système 32 bits.
   2. Demandez ; lire 4096 octets. (Taille du tampon allouée en mémoire à partir des informations statistiques.)
   3. Une chaîne courte est lue, c'est-à-dire 18 octets.
   4. Vérifiez si un trou est nécessaire, non.
   5. Écrire le tampon dans la cible.
   6. Soustrayez 18 de la taille de lecture maximale.
   7. Demandez ; lire 4096 octets.
   8. 0 octet, car tous ont été consommés lors de la première lecture.
   9. Renvoyer le succès.
6. Tout va bien. Mettre à jour les drapeaux pour le fichier.
7. BIEN.

Peut être lié, mais les appels d'attributs étendus échoueront sur sysfs :

[[email protected] eth0]# adresse lsattr

lsattr :ioctl inapproprié pour l'appareil lors de la lecture des drapeaux sur l'adresse

[[email protected] eth0]#

En regardant mon strace, il semble que rsync essaie d'extraire les attributs étendus par défaut :

22964 <... getxattr resumed> , 0x7fff42845110, 132) =-1 ENODATA (Aucune donnée disponible)

J'ai essayé de trouver un indicateur pour donner rsync pour voir si ignorer les attributs étendus résout le problème mais je n'ai rien trouvé (--xattrs les active à destination).