☰

일상적인 백업을 수행하는 동안 rsync에 IO 오류가 발생함

tag-icon • tag-icon rsync linux-kernel
일상적인 백업을 수행하는 동안 rsync에 IO 오류가 발생함

나는 매우 제한된 Linux 온보드(Optware/IPKG로 약간 강화되었지만)를 갖춘 샘플 NAS 서버(QNAP TS-210)를 가지고 있습니다. 저는 리눅스 초보자입니다. 인터넷을 검색한 후 NAS 하드 드라이브와 외부 USB 드라이브 간의 파일 동기화를 위해 rsync를 사용하고 이 스크립트를 주기적으로 실행하기 위해 CRON을 사용하여 나만의 백업 스크립트를 작성할 수 있었습니다.

며칠 전까지만 해도 모든 것이 괜찮았습니다. 백업 스크립트에 의해 생성된 이메일에는 IO error encountered -- skipping file deletion백업 중인 많은 리소스(폴더)에 대한 정보가 포함되기 시작했습니다. SSH를 통해 동일한 스크립트를 실행하면 " cannot send file with empty name in..."와 " rsync error: some files/attrs were not transferred (see previous errors)"라는 오류 줄이 많이 나타납니다.

백업하는 콘텐츠는 100% Windows에서 가져옵니다(저는 컴퓨터를 백업할 때만 NAS를 사용합니다). 이 시스템에서는 이름이 비어 있는 파일을 생성할 수 없습니다. 이 문제는 며칠 동안만 발생했으며 몇 주(휴가) 동안 백업을 수정하지 않았습니다. 따라서 이는 Linux(내 NAS 온보드) 문제여야 합니다.

질문: 파일이 빈 이름으로 표시되는 원인은 무엇입니까? 어떻게 제거할 수 있습니까( cdrsync 보고서에 언급된 폴더로 이동하여 수행할 때 ls -ls"빈 이름의 파일"과 같은 것이 표시되지 않음) 다음 rsync 패스는 이러한 오류 없이 종료됩니다. 그리고 마지막으로, 앞으로 그러한 파일을 얻는 것을 방지하는 방법은 무엇입니까?

답변1

나는 이것이 rsync의 잘못이라고 생각하지 않습니다. 관련 코드가 있기 때문에 이것을 커널 수준 문제로 올바르게 태그했다고 생각합니다.rsync flist.c소스 에서읽는다:

1729         for (errno = 0, di = readdir(d); di; errno = 0, di = readdir(d)) {
1730                 unsigned name_len;
1731                 char *dname = d_name(di);
...
1746                 if (dname[0] == '\0') {
1747                         io_error |= IOERR_GENERAL;
1748                         rprintf(FERROR_XFER,
1749                                 "cannot send file with empty name in %s\n",
1750                                 full_fname(fbuf));

실제로 해당 코드 줄은 rsync 개발자가 추가한 것입니다.2007년 8월에 다시특히 이 경우:

If readdir() gives us an empty name, reject it.

즉, readdir()자체(디렉토리의 파일 목록을 반환하는 커널 함수)가 빈 문자열이 있는 항목을 반환했습니다. 규정에 따르면 그런 일은 절대 일어나서는 안 됩니다. 에서 인용공개 그룹 사양:

The readdir() function shall not return directory entries containing empty names.

일종의 일시적인 문제였던 것 같습니다. ls해당 디렉토리에서 작업을 수행할 때 이미 사라졌기 때문입니다(이 디렉토리도 사용했으므로 readdir()사라졌습니다).

귀하의 질문에 대한 답변은 다음과 같습니다.

  1. 원인은 손상된 파일 시스템인 것 같습니다. 커널 드라이버 버그부터 하드웨어 결함까지 모든 것이 원인일 수 있습니다.rsync 중인 디렉토리가 심볼릭 링크를 통해 액세스되는지 또는 문제가 있을 수 있는 네트워크 경계 자체를 넘어서는지 확인하는 것도 가치가 있습니다.

  2. 이를 제거하려면: 일반적인 파일 시스템 복구 체크리스트: fsck 등

  3. 미래를 피하기 위해: 재귀 목록을 미리 강제하도록 스크립트에 지시할 수 있다고 가정합니다. 그러나 이미 주목을 받고 있으므로(그리고 휴가에서 돌아왔기 때문에) 계속 지켜보는 것이 옳은 일인 것 같습니다. 그런 일이 다시 발생하면 상자 위로 점프하세요.

이것이 도움이 되었기를 바랍니다. 행운을 빕니다!

관련 정보