나는 이 질문에 대한 대답이 일반적으로 "적절하다고 판단될 때"이거나 다른 모호한 대답이라는 것을 알고 있습니다. 호스트가 하드 재부팅하면 최근에 작성된 일부 파일에 마지막 데이터가 없거나 심지어 손상되는 경우를 여러 번 보았습니다. 하지만 최근에 나는 많은 I/O를 유발하는 코드 디버깅을 누군가를 돕고 있었습니다. 자세히 조사해 보면 이는 임시 파일을 여는 tmpfile(3)방법(파일이 열리자마자 링크가 해제됨을 의미함)을 사용하고 다음 단계를 수천 번 반복하는 매우 잘못 작성된 코드라는 것이 밝혀졌습니다 .
- 파일에 몇 바이트를 씁니다.
- 파일의 시작 부분으로 다시 이동을 사용합니다
seek. - 이 바이트를 읽으십시오.
- 파일을 0으로 자르십시오
ftruncate.
그런 다음 동일한 작업을 반복합니다. 파일 시스템이 xfs이고 최소 파일 크기가 4k이므로 이 루프가 반복되는 횟수를 세고 4k를 곱하면 시스템에서 보고하는 I/O 쓰기 양과 정확히 일치하는 것으로 보입니다. 매번 ftruncate, 또는 write즉시 새로운 블록이 디스크에 할당됩니다. 이로 인해 호스트에 많은 문제가 발생했으며 iowait이러한 프로세스 중 여러 개가 동일한 호스트에서 함께 실행되면 실제로 로드가 발생하고 디스크가 매우 느려집니다.
이제 이 매우 비효율적인 코드(발견 이후 수정됨)를 제쳐두고 I/O 로드가 왜 그렇게 높은지 궁금합니다. 데이터가 계속해서 플러시되고 각 ftruncate(또는 write후속) 4k가 계속해서 할당되는 것처럼 보입니다 . 그래서 데이터(그리고 어떤 데이터)가 물리적 디스크에 언제 어떻게 플러시되는지 알아내려고 노력하고 있습니다. 단순한 메타데이터인가요, 아니면 데이터 자체인가요?
그런데 tmpfile파일을 열지 마세요.O_SYNCO_DIRECT