rsync
Archlinux에서 파일을 백업하는 데 사용하는 bash 스크립트가 있습니다 . rsync
에서 파일을 복사하는 데 실패했지만 /sys
잘 cp
작동하는 것으로 나타났습니다 .
# 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 파일의 상태
아래 디렉토리로 가서 /sys
a를 수행 하면 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 실패에 대한 가장 쉬운 설명은 아마도 예일 것입니다.
address
18바이트라는 이름의 파일이 있다고 가정해 보겠습니다 . ls
또는 stat
파일 중 하나 가 4096바이트를 보고합니다.
재동기화
- 파일 설명자 fd를 엽니다.
- fstat(fd)를 사용하여 크기와 같은 정보를 얻습니다.
- 읽기 크기 바이트(예: 4096)로 설정합니다.253호선링크된 코드의@mattdm.
read_size == 4096
- 묻다; 읽기: 4096바이트.
- 짧은 문자열, 즉 18바이트를 읽습니다.
nread == 18
read_size = read_size - nread (4096 - 18 = 4078)
- 묻다; 읽기: 4078바이트
- 0바이트 읽기(첫 번째 읽기가 파일의 모든 바이트를 소비했기 때문에)
nread == 0
,255호선- 바이트를 읽을 수 없습니다
4096
. 제로아웃 버퍼. - 오류를 설정합니다
ENODATA
. - 반품.
- 오류를 신고하세요.
- 다시 해 보다. (루프 위).
- 실패하다.
- 오류를 신고하세요.
- 괜찮은.
이 프로세스 동안 실제로 전체 파일을 읽습니다. 그러나 사용 가능한 크기가 없으므로 결과를 검증할 수 없습니다. 따라서 실패는 선택 사항일 뿐입니다.
CP
- 파일 설명자 fd를 엽니다.
- fstat(fd)를 사용하여 st_size와 같은 정보를 얻습니다(lstat 및 stat도 사용함).
파일이 희소할 가능성이 있는지 확인하십시오. 즉, 파일에 구멍 등이 있습니다.
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
희소 파일로 분류됩니다.익스텐트 복사로 파일 읽기를 시도합니다(더 효율적인 복사 방법)정상 스파스 파일), 실패합니다.
- 스파스 복사로 복사합니다.
- MAXINT의 최대 읽기 크기로 시작합니다.
일반적으로18446744073709551615
32비트 시스템의 바이트입니다. - 묻다; 4096바이트를 읽습니다. (상태 정보에서 메모리에 할당된 버퍼 크기입니다.)
- 짧은 문자열, 즉 18바이트를 읽습니다.
- 구멍이 필요한지 확인하세요. 아니요.
- 대상에 버퍼를 씁니다.
- 최대 읽기 크기에서 18을 뺍니다.
- 묻다; 4096바이트를 읽습니다.
- 첫 번째 읽기에서 모두 소비되었으므로 0바이트입니다.
- 반환 성공.
- MAXINT의 최대 읽기 크기로 시작합니다.
- 다 괜찮아. 파일의 플래그를 업데이트합니다.
- 괜찮은.
답변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으로 채워지는 것입니다. 널 바이트는 일반적으로 무시되므로 대부분의 경우에는 차이가 없습니다.