fsync()가 먼저 호출될 때 rename()이 더 오래 걸리는 이유는 무엇입니까?

이 테스트에서 fsync()가 먼저 호출될 때 rename()이 더 오래 걸리는 이유는 무엇입니까?

환경: btrfs, 기계식 하드 디스크, Debian 9 컨테이너, 커널 5.0.17-200.fc29.x86_64에서 실행.

테스트 명령:dpkg -r linux-image-4.9.0-9-amd64 >/dev/null 2>&1 && sync && time perf_4.9 trace --no-inherit -s dpkg $FORCE_UNSAFE_IO -i linux-image-4.9.0-9-amd64_4.9.168-1_amd64.deb && time sync

FORCE_UNSAFE_IO=""FORCE_UNSAFE_IO="--force-unsafe-io"vs. 결과를 비교해 보세요 .

 dpkg (31632), 374488 events, 100.0%

   syscall            calls    total       min       avg       max      stddev
                               (msec)    (msec)    (msec)    (msec)        (%)
   --------------- -------- --------- --------- --------- ---------     ------
   fsync               3442 14849.586     0.002     4.314   149.959      4.11%
   rename              8463 14573.509     0.003     1.722   358.675      4.80%
   wait4                  7  8043.762     0.004  1149.109  8028.468     99.78%
   read               44025  2151.135     0.000     0.049     3.732      0.57%
   open               19301   213.628     0.002     0.011     0.375      0.90%
   write               7846   165.460     0.003     0.021     0.149      0.42%
   sync_file_range     6834    96.513     0.001     0.014     0.822      2.20%
...
real    0m41.703s
user    0m9.709s
sys 0m6.586s

real    0m0.162s
user    0m0.000s
sys 0m0.003s

 dpkg (1919), 334232 events, 100.0%

   syscall            calls    total       min       avg       max      stddev
                               (msec)    (msec)    (msec)    (msec)        (%)
   --------------- -------- --------- --------- --------- ---------     ------
   wait4                  7  8290.981     0.007  1184.426  8279.676     99.84%
   read               44399  2168.096     0.000     0.049     2.146      0.50%
   fsync                 25   653.530     0.006    26.141    68.754      8.65%
   rename              8463   522.282     0.003     0.062    69.620     22.53%
   open               12467   163.671     0.002     0.013     0.217      0.97%
   write               7846   160.979     0.003     0.021     0.356      0.50%
   sync_file_range     3417    89.676     0.010     0.026     0.841      2.05%
...
real    0m13.498s
user    0m9.643s
sys 0m5.517s

real    0m0.146s
user    0m0.000s
sys 0m0.004s

현재 전략 dpkg(예: Debian 9)은 생각보다 더 복잡합니다. 그러나 그것이 실제로 사건에 영향을 미칠지는 확실하지 않습니다. 더 자세한 내용을 원하시면 이 질문에 몇 가지 배경 지식이 있습니다.AIO fsync가 dpkg 성능을 향상시킬 수 있습니까?

이것이 관련이 있는지는 모르겠지만 일부 파일 시스템에서는 fsync()가 디렉토리를 효과적으로 동기화할 수도 있다는 것을 알았습니다. 이는 fsync()가 반환되기 전에 새로 생성된 파일이 디스크에 표시되도록 하기 위한 것입니다. ext2에서는 이런 일이 발생하지 않지만 ext4에서는 발생한다는 내용을 어딘가에서 읽었습니다. 부분적인 증거로 다음을 참조하세요.ext4: 이번에는 fsync가 로그 없이 상위 디렉터리를 동기화하도록 합니다.

sync추적 시간에 놀랐 다면 dpkg개별 fsync() 호출을 전역 sync() 호출로 대체하는 패치를 적용하면 전체 시간이 약 13초로 단축되는 것 같습니다. 내 시스템에서 어떤 결함도 발견하지 못했습니다. dpkg나는 다른 잠재적인 부작용 때문에 이 방법의 사용을 중단했습니다.[1][2]