Why does rsync fail to copy files from /sys in Linux?

Question

I have a bash script which uses rsync to backup files in Archlinux. I noticed that rsync failed to copy a file from /sys, while cp worked just fine:

# rsync /sys/class/net/enp3s1/address /tmp    
rsync: read errors mapping "/sys/class/net/enp3s1/address": No data available (61)
rsync: read errors mapping "/sys/class/net/enp3s1/address": No data available (61)
ERROR: address failed verification -- update discarded.
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1052) [sender=3.0.9]

# cp  /sys/class/net/enp3s1/address /tmp   ## this works

I wonder why does rsync fail, and is it possible to copy the file with it?

Answer 1

First off /sys is a pseudo file system. If you look at /proc/filesystems you will find a list of registered file systems where quite a few has nodev in front. This indicates they are pseudo filesystems. This means they exists on a running kernel as a RAM-based filesystem. Further they do not require a block device.

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

At boot the kernel mount this system and updates entries when suited. E.g. when new hardware is found during boot or by udev.

In /etc/mtab you typically find the mount by:

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

For a nice paper on the subject read Patric Mochel's – The sysfs Filesystem.

---

stat of /sys files

If you go into a directory under /sys and do a ls -l you will notice that all files has one size. Typically 4096 bytes. This is reported by 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
...

Further you can do a stat on a file and notice another distinct feature; it occupies 0 blocks. Also inode of root (stat /sys) is 1. /stat/fs typically has inode 2. etc.

rsync vs. cp

The easiest explanation for rsync failure of synchronizing pseudo files is perhaps by example.

Say we have a file named address that is 18 bytes. An ls or stat of the file reports 4096 bytes.

---

rsync

1. Opens file descriptor, fd.
2. Uses fstat(fd) to get information such as size.
3. Set out to read size bytes, i.e. 4096. That would be line 253 of the code linked by @mattdm. read_size == 4096
   1. Ask; read: 4096 bytes.
   2. A short string is read i.e. 18 bytes. nread == 18
   3. read_size = read_size - nread (4096 - 18 = 4078)
   4. Ask; read: 4078 bytes
   5. 0 bytes read (as first read consumed all bytes in file).
   6. nread == 0 , line 255
   7. Unable to read 4096 bytes. Zero out buffer.
   8. Set error ENODATA.
   9. Return.
4. Report error.
5. Retry. (Above loop).
6. Fail.
7. Report error.
8. FINE.

During this process it actually reads the entire file. But with no size available it cannot validate the result – thus failure is only option.

cp

1. Opens file descriptor, fd.
2. Uses fstat(fd) to get information such as st_size (also uses lstat and stat).

3. Check if file is likely to be sparse. That is the file has holes 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);
   

   As stat reports file to have zero blocks it is categorized as sparse.

4. Tries to read file by extent-copy (a more efficient way to copy normal sparse files), and fails.

5. Copy by sparse-copy.
   1. Starts out with max read size of MAXINT.
      Typically 18446744073709551615 bytes on a 32 bit system.
   2. Ask; read 4096 bytes. (Buffer size allocated in memory from stat information.)
   3. A short string is read i.e. 18 bytes.
   4. Check if a hole is needed, nope.
   5. Write buffer to target.
   6. Subtract 18 from max read size.
   7. Ask; read 4096 bytes.
   8. 0 bytes as all got consumed in first read.
   9. Return success.
6. All OK. Update flags for file.
7. FINE.

Answer 2

Rsync has code which specifically checks if a file is truncated during read and gives this error — ENODATA. I don't know why the files in /sys have this behavior, but since they're not real files, I guess it's not too surprising. There doesn't seem to be a way to tell rsync to skip this particular check.

I think you're probably better off not rsyncing /sys and using specific scripts to cherry-pick out the particular information you want (like the network card address).

Answer 3

Might be related, but extended attribute calls will fail on sysfs:

[root@hypervisor eth0]# lsattr address

lsattr: Inappropriate ioctl for device While reading flags on address

[root@hypervisor eth0]#

Looking at my strace it looks like rsync tries to pull in extended attributes by default:

22964 <... getxattr resumed> , 0x7fff42845110, 132) = -1 ENODATA (No data available)

I tried finding a flag to give rsync to see if skipping extended attributes resolves the issue but wasn't able to find anything (--xattrs turns them on at the destination).

Answer 4

Rsync normally read the file's information, transfer file contents or delta's to a temporary file in the destination directory, then after verifying the file's data it renames it to the destination filename.

I believe the problem with sysfs is that all files shows as 4k (one memory page) yet they may contain only a few bytes. To avoid copying a potentially corrupt file to the destination rsync cancels the copy when it sees a mismatch between the file's metadata and what was actually copied.

At least on rsync v3.0.6 this behaviour can be avoided using the --inplace switch. Rsync will still detect errors but since the destination files will already have been overwriten when it does it will leave the potentially corrupt files there.

Note though that a side effect of it is that files end up being zero-padded to 4k as this is the size rsync thinks the files are. It shouldn't make a difference in most cases as null bytes are usually ignored.