Прежде всего /sys псевдо файловая система. Если Вы смотрите на /proc/filesystems Вы найдете список зарегистрированных файловых систем, где довольно многие имеют nodev впереди. Это указывает, что они - псевдо файловые системы. Это означает, что они существуют на рабочем ядре как основанная на RAM файловая система. Далее они не требуют блочного устройства.

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

При начальной загрузке ядро монтирует эту систему, и обновляет записи при удовлетворении. Например, когда новые аппаратные средства найдены во время начальной загрузки или udev.

В /etc/mtab Вы обычно находите монтирование:

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

Поскольку хорошая статья о предмете считала Patric Mochel – sysfs Файловая система.

статистика/sys файлов

Если Вы входите в каталог под /sys и сделайте a ls -l Вы заметите, что все файлы имеют один размер. Обычно 4 096 байтов. Этим сообщают 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
...

Далее можно сделать a stat на файле и уведомлении другая отличная функция; это занимает 0 блоков. Также inode корня (статистика/sys) равняется 1. /stat/fs обычно имеет inode 2. и т.д.

rsync по сравнению с CP

Самое легкое объяснение rsync отказа синхронизации псевдо файлов, возможно, примером.

Скажите, что нам назвали файл address это составляет 18 байтов. ls или stat из файла сообщает о 4 096 байтах.

rsync

1. Открывает дескриптор файла, fd.
2. Использование fstat (fd) для получения информации, такой как размер.
3. Изложенный для чтения байтов размера, т.е. 4096. Это было бы строкой 253 из кода, связанного @mattdm. read_size == 4096
   1. Спросите; читайте: 4 096 байтов.
   2. Короткая строка читается т.е. 18 байтов. nread == 18
   3. read_size = read_size - nread (4096 - 18 = 4078)
   4. Спросите; читайте: 4 078 байтов
   5. 0-байтовое чтение (как сначала считано использованный все байты в файле).
   6. nread == 0 , строка 255
   7. Не мог читать 4096 байты. Нуль буферизует.
   8. Ошибка набора ENODATA.
   9. Вернуть.
4. Ошибка отчета.
5. Повторить. (Выше цикла).
6. Сбой.
7. Ошибка отчета.
8. Отлично.

Во время этого процесса это на самом деле читает весь файл. Но без размера, доступного, это не может проверить результат – таким образом, отказ является только опцией.

CP

1. Открывает дескриптор файла, fd.
2. Использование fstat (fd) для получения информации, такой как st_size (также использует lstat и статистику).

3. Проверьте, будет ли файл, вероятно, редок. Это - файл, имеет дыры и т.д.

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

   Как stat файл отчетов, чтобы иметь нулевые блоки это категоризировано как редкое.

4. Попытки считать файл копией степени (более эффективный способ скопировать нормальные редкие файлы), и сбои.

5. Копия редкой копией.
   1. Начинается с макс. размером чтения MAXINT.
      Обычно 18446744073709551615 байты в системе на 32 бита.
   2. Спросите; считайте 4 096 байтов. (Размер буфера выделяется в памяти от информации о статистике.)
   3. Короткая строка читается т.е. 18 байтов.
   4. Проверьте, необходима ли дыра, нет.
   5. Буфер записи для предназначения.
   6. Вычтите 18 из макс. размера чтения.
   7. Спросите; считайте 4 096 байтов.
   8. 0 байтов, поскольку все были использованы в первом чтении.
   9. Возвратите успех.
6. Весь OK. Обновление отмечает для файла.
7. Отлично.

Мог бы быть связан, но расширился, вызовы атрибута перестанут работать на sysfs:

[root@hypervisor eth0] # lsattr адрес

lsattr: Несоответствующий ioctl для устройства При чтении флагов на адресе

[root@hypervisor eth0] #

При рассмотрении моего strace, на который это похоже, rsync пытается вытянуть в расширенных атрибутах по умолчанию:

22964 <... getxattr возобновленный>, 0x7fff42845110, 132) =-1 ENODATA (Никакие доступные данные)

Я пытался найти, что флаг дает rsync, чтобы видеть, если пропуск расширенных атрибутов решает вопрос, но не смог найти что-либо (--xattrs включает их в месте назначения).

Rsync normalmente lee la información del archivo, transfiere el contenido del archivo o delta a un archivo temporal en el directorio de destino, luego, después de verificar los datos del archivo, lo renombra al nombre del archivo de destino.

Creo que el problema con sysfs es que todos los archivos se muestran como 4k (una página de memoria )pero pueden contener solo unos pocos bytes. Para evitar copiar un archivo potencialmente dañado en el destino, rsync cancela la copia cuando detecta una discrepancia entre los metadatos del archivo y lo que realmente se copió.

Al menos en rsync v3.0.6, este comportamiento se puede evitar usando el interruptor --inplace. Rsync aún detectará errores, pero dado que los archivos de destino ya se habrán sobrescrito cuando lo haga, dejará los archivos potencialmente corruptos allí.

Sin embargo, tenga en cuenta que un efecto secundario es que los archivos terminan siendo cero -rellenados a 4k, ya que este es el tamaño que rsync cree que tienen los archivos. No debería marcar la diferencia en la mayoría de los casos, ya que los bytes nulos generalmente se ignoran.