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?

  • 4
    Why do you want to copy /sys/? Apr 24, 2013 at 16:38
  • 1
    @frostschutz I use the command in the OP to copy the MAC-address of a network card (as a file) Apr 24, 2013 at 16:52
  • @eugeney So, why isn't it sufficient to backup the config file where the MAC address is set from?
    – depquid
    Apr 24, 2013 at 21:05
  • @eugeney Is it even possible to write to /sys/class/net/*/address (I get "permission denied" when I try it)? If not, then you aren't making a real/useful backup since it can't be restored.
    – depquid
    Apr 24, 2013 at 21:11

4 Answers 4


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.


  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.


  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.

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

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).

  • Pfft, where's the fun in not figuring out why rsync in particular fails?
    – Bratchley
    Apr 24, 2013 at 18:29
  • Sorry, I wasn't clear. Rsync specifically checks for files truncated during read and throws this error.
    – mattdm
    Apr 24, 2013 at 18:32
  • 4
    I'd presume they have this behaviour because until you actually read them, what's "there" is not absolutely certain; the read is really a request for dynamic information from the kernel. So the kernel does not try to give accurate details WRT to the file size, etc, in advance, and as you point out, rsync takes such a discrepancy as a bad sign.
    – goldilocks
    Apr 24, 2013 at 19:19

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).


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .