"rsync" 명령을 사용할 때 "--modify-window=1"을 사용해야 하는 이유는 무엇입니까?

Question 1

"modify_window" 작동 방식에 대한 혼란을 피하기 위해 어느 방향에서든 확인합니다. (이 내용을 소스코드로 읽으시려면 util.c::cmp_time()을 확인해주세요.)

이것은 의미한다,

A가 B보다 최신인 경우 A가 B + update_window보다 최신인지 확인합니다.
B가 A보다 최신인 경우 B가 여전히 A + 수정 창보다 최신인지 확인합니다.

원본 A의 시간은 123이지만 백업 파일 시스템이 형편없어서 복사본 B의 시간은 122(A를 B보다 최신) 또는 시간 124(B를 A보다 최신)로 끝냅니다.

수정 창 = 1이면 어떻게 되나요?

A(123)가 B(122)보다 최신인 경우 A(123)가 여전히 B(122+1 = 123)보다 최신인지 확인합니다.
B(124)가 A(123)보다 최신인 경우 B(124)가 여전히 A(123+1 = 124)보다 최신인지 확인합니다.

두 경우 모두 결과는 동일하므로 수정 창 = 1이면 어느 방향에서든 시간을 1초씩 오프셋하는 데 충분합니다.

rsync 매뉴얼 페이지에 따르면 이는 FAT32에 충분할 것입니다.

당신이 인용한 문서에 따르면(122를 124로 바꾸는 것, 도대체 무엇입니까) 이것은 충분하지 않습니다.

따라서 배심원 단은 아직 이에 대해 판단하지 않았습니다.

실험을 통해 Linux에서 NTFS(-3g)와 FAT32를 사용하면 수정_window = 1이 제대로 작동하는 것 같습니다.

내 테스트 설정은 다음과 같습니다.

truncate -s 100M ntfs.img fat32.img
mkfs.ntfs -F ntfs.img
mkfs.vfat -F 32 fat32.img
mount -o loop ntfs.img /tmp/ntfs/
mount -o loop fat32.img /tmp/fat32/

따라서 1억 NTFS/FAT32 파일 시스템입니다.

다양한 타임스탬프가 포함된 수천 개의 파일을 만듭니다.

cd /tmp/ntfs

for f in {000..999}
do
    sleep 0.0$RANDOM # widens the timestamp range
    touch "$f"
done

예를 들어:

# stat --format=%n:%y 111 222 333
111:2018-08-10 20:19:10.011984300 +0200
222:2018-08-10 20:19:13.553878700 +0200
333:2018-08-10 20:19:17.765753000 +0200

귀하에 20:19:10.011따르면 2018-08-10 20:19:12.000.

그럼 무슨 일이 일어나는지 봅시다. 먼저, 이 모든 파일을 FAT32로 복사하세요.

# rsync -a /tmp/ntfs/ /tmp/fat32/

그런 다음 제거하고 다시 설치할 때까지 타임스탬프가 실제로 정확하다는 것을 확인했습니다.

# umount /tmp/fat32
# mount -o loop fat32.img /tmp/fat32

비교하다:

# stat --format=%n:%y /tmp/{ntfs,fat32}/{111,222,333}
/tmp/ntfs/  111:2018-08-10 20:19:10.011984300 +0200
/tmp/fat32/ 111:2018-08-10 20:19:10.000000000 +0200
/tmp/ntfs/  222:2018-08-10 20:19:13.553878700 +0200
/tmp/fat32/ 222:2018-08-10 20:19:12.000000000 +0200
/tmp/ntfs/  333:2018-08-10 20:19:17.765753000 +0200
/tmp/fat32/ 333:2018-08-10 20:19:16.000000000 +0200

그래서 이것은 나에게 충격적인 것 같습니다. Windows가 동일한 방식으로 이를 수행하는지 모르겠지만 Linux와 rsync를 사용할 때 발생하는 일입니다.

다시 복사할 때 rsync가 수행하는 작업:

# rsync -av --dry-run /tmp/ntfs/ /tmp/fat32
sending incremental file list
./
000
001
002
035
036
...
963
964
997
998
999

따라서 목록에 약간의 공백이 있지만 전체적으로 꽤 많은 파일을 다시 복사하게 됩니다.

사용하면 --modify-window=1목록이 비어 있습니다.

# rsync -av --dry-run --modify-window=1 /tmp/ntfs/ /tmp/fat32/
sending incremental file list
./

따라서 적어도 Linux의 경우 매뉴얼 페이지는 정확합니다. 오프셋은 결코 1보다 크지 않은 것 같습니다. (글쎄, 1에 점수를 더한 값이지만 그것도 무시됩니다.)

그렇다면 --modify-time=2그것을 사용해야 할까요? 이것이 실제로 가능한 시나리오라는 것을 실험적으로 증명할 수 있을 때까지는 말이죠. 그럼에도 불구하고 말하기는 어렵습니다. 우선, 이것은 끔찍한 해킹입니다. 시간 창이 클수록 실제 수정 사항을 놓칠 가능성이 커집니다.

FAT32 타임스탬프 반올림 방법과 관련 없는 변경 사항 도 --modify-time=1무시되었습니다. 양방향이기 때문에 FAT32는 플로어만 수행할 수 있고 rsync는 FAT32로 복사할 때 이를 무시하고(대상 파일은 이전 파일만 가능) 그 반대의 경우도 마찬가지입니다. FAT32에서 복사할 때도 마찬가지입니다(대상 파일은 최신 파일만 가능).

이 문제를 처리하는 데 이보다 더 좋은 옵션은 없는 것 같습니다.

또한 커널 소스 코드에서 이 동작을 추적해 보았으나 불행하게도 주석(linux/fs/fat/misc.c)에서는 많은 정보를 제공하지 못했습니다.

/*
 * The epoch of FAT timestamp is 1980.
 *     :  bits :     value
 * date:  0 -  4: day   (1 -  31)
 * date:  5 -  8: month (1 -  12)
 * date:  9 - 15: year  (0 - 127) from 1980
 * time:  0 -  4: sec   (0 -  29) 2sec counts
 * time:  5 - 10: min   (0 -  59)
 * time: 11 - 15: hour  (0 -  23)
 */

따라서 이를 기반으로 FAT 타임스탬프는 5비트를 사용하여 초를 표시하므로 32개의 가능한 상태만 얻을 수 있으며 그 중 30개가 사용됩니다. 변환은 간단한 비트 이동으로 수행됩니다.

fs/fat/misc.c::fat_time_unix2fat()에서

    /* 0~59 -> 0~29(2sec counts) */
    tm.tm_sec >>= 1;

즉 0은 0, 1은 0, 2는 1, 3은 1, 4는 2 등...

fs/fat/misc.c::fat_time_fat2unix()에서

    second =  (time & 0x1f) << 1;

위와는 달리 0x1f0~29초를 나타내는 FAT 시간의 비트 0~4만 가져오는 비트마스크입니다.

이것이 원래와 다른 경우 댓글에 아무것도 표시되지 않습니다.

Raymond Chen은 Windows가 라운드 시간에 왜 그런 문제를 겪는지에 대한 흥미로운 기사를 게시했습니다.https://blogs.msdn.microsoft.com/oldnewthing/20140903-00/?p=83

좋습니다. 그런데 타임스탬프가 항상 가장 가까운 2초 간격으로 증가하는 이유는 무엇입니까? 가장 가까운 2초 간격으로 반올림하면 어떨까요? 이렇게 하면 타임스탬프가 최대 1초씩 변경됩니다.

가장 가까운 간격으로 반올림하면 파일이 시간이 거꾸로 흘러 문제가 발생할 수 있기 때문입니다. (인과관계가 문제가 될 수 있습니다.)

이에 따르면 Windows 도구에는 "소스 파일이 대상 파일보다 최신인 경우에만 복사"라는 플래그가 xcopy있습니다 . /D기본적으로 무엇을 rsync --update할 cp --update것인지.

파일이 과거 1초 전에 생성된 것처럼 보이도록 시간을 반올림하면(Linux에서처럼) 명령이 실행될 때마다 파일이 다시 복사됩니다. 시간을 반올림하면 이 문제가 해결됩니다.

OTOH Windows 솔루션은 이러한 파일을 다시 복사할 때 동일한 문제를 일으킬 수 있습니다. 실제보다 최신의 파일을 복사하므로 롤업이 두 번 발생하지 않도록 주의해야 합니다.

무엇을 하든 항상 잘못된 일이고, 타임스탬프를 올바르게 저장할 수 없는 파일 시스템은 단지 귀찮은 일입니다.

Answer