/sys 파일의 상태

/sys 파일의 상태

rsyncArchlinux에서 파일을 백업하는 데 사용하는 bash 스크립트가 있습니다 . rsync에서 파일을 복사하는 데 실패했지만 /syscp작동하는 것으로 나타났습니다 .

# 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

왜 실패하는지 궁금하고 rsync, 함께 파일을 복사할 수 있나요?

답변1

우선 /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 파일의 상태

아래 디렉토리로 가서 /sysa를 수행 하면 ls -l모든 파일의 크기가 동일하다는 것을 알 수 있습니다. 일반적으로 4096바이트입니다. 이것은 에 의해 보고됩니다 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
...

stat또한 파일에 대해 작업을 수행 하면 또 다른 독특한 기능을 확인할 수 있습니다. 0 블록을 차지합니다. 또한 루트의 inode(stat /sys)는 1입니다. /stat/fs일반적으로 inode는 2입니다.

rsync 대 cp

의사 파일 동기화의 rsync 실패에 대한 가장 쉬운 설명은 아마도 예일 것입니다.

address18바이트라는 이름의 파일이 있다고 가정해 보겠습니다 . ls또는 stat파일 중 하나 가 4096바이트를 보고합니다.


재동기화

  1. 파일 설명자 fd를 엽니다.
  2. fstat(fd)를 사용하여 크기와 같은 정보를 얻습니다.
  3. 읽기 크기 바이트(예: 4096)로 설정합니다.253호선링크된 코드의@mattdm.read_size == 4096
    1. 묻다; 읽기: 4096바이트.
    2. 짧은 문자열, 즉 18바이트를 읽습니다.nread == 18
    3. read_size = read_size - nread (4096 - 18 = 4078)
    4. 묻다; 읽기: 4078바이트
    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 및 stat도 사용함).
  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);
    

    블록이 0개인 보고서 파일 은 stat희소 파일로 분류됩니다.

  4. 익스텐트 복사로 파일 읽기를 시도합니다(더 효율적인 복사 방법)정상 스파스 파일), 실패합니다.

  5. 스파스 복사로 복사합니다.
    1. MAXINT의 최대 읽기 크기로 시작합니다.
      일반적으로 1844674407370955161532비트 시스템의 바이트입니다.
    2. 묻다; 4096바이트를 읽습니다. (상태 정보에서 메모리에 할당된 버퍼 크기입니다.)
    3. 짧은 문자열, 즉 18바이트를 읽습니다.
    4. 구멍이 필요한지 확인하세요. 아니요.
    5. 대상에 버퍼를 씁니다.
    6. 최대 읽기 크기에서 18을 뺍니다.
    7. 묻다; 4096바이트를 읽습니다.
    8. 첫 번째 읽기에서 모두 소비되었으므로 0바이트입니다.
    9. 반환 성공.
  6. 다 괜찮아. 파일의 플래그를 업데이트합니다.
  7. 괜찮은.

답변2

재동기화는암호특히 파일을 읽는 동안 잘렸는지 확인하고 다음 오류가 발생하는지 확인합니다 — ENODATA. 모르겠습니다의 파일/sys 이런 동작이 있지만 실제 파일이 아니기 때문에 그다지 놀라운 것은 아닙니다. rsync에게 이 특정 검사를 건너뛰도록 지시하는 방법은 없는 것 같습니다.

/sys내 생각에는 재동기화를 하지 않고 특정 스크립트를 사용하여 원하는 특정 정보(예: 네트워크 카드 주소)를 선별하는 것이 더 나을 것 같습니다 .

답변3

관련이 있을 수 있지만 확장된 속성 호출은 sysfs에서 실패합니다.

[root@hypervisor eth0]# lsattr 주소

lsattr: 주소의 플래그를 읽는 동안 장치에 대한 부적절한 ioctl

[루트@하이퍼바이저 eth0]#

내 strace를 보면 rsync가 기본적으로 확장 속성을 가져오려고 시도하는 것 같습니다.

22964 <... getxattr 재개> , 0x7fff42845110, 132) = -1 ENODATA(사용 가능한 데이터 없음)

확장 속성을 건너뛰면 문제가 해결되는지 확인하기 위해 rsync를 제공하는 플래그를 찾으려고 했지만 아무 것도 찾을 수 없었습니다(--xattrs .~에목적지에서).

답변4

Rsync는 일반적으로 파일 정보를 읽고 파일 내용이나 델타를 대상 디렉터리의 임시 파일로 전송한 다음 파일 데이터를 확인한 후 대상 파일 이름으로 이름을 바꿉니다.

나는 sysfs의 문제점은 모든 파일이 4k(1개의 메모리 페이지)로 표시되지만 몇 바이트만 포함할 수 있다는 점이라고 생각합니다. 잠재적으로 손상된 파일을 대상으로 복사하는 것을 방지하기 위해 rsync는 파일의 메타데이터와 실제로 복사된 내용이 일치하지 않는 경우 복사를 취소합니다.

최소한 rsync v3.0.6에서는 --inplace스위치를 사용하여 이 동작을 피할 수 있습니다. Rsync는 여전히 오류를 감지하지만 대상 파일은 이미 덮어쓰기되었으므로 잠재적으로 손상된 파일이 그대로 남아 있게 됩니다.

하지만 그 부작용은 파일이 rsync가 생각하는 크기인 4k로 0으로 채워지는 것입니다. 널 바이트는 일반적으로 무시되므로 대부분의 경우에는 차이가 없습니다.

관련 정보