장로cfq-iosched.txt여러 곳에서 "비동기" 또는 "비동기" 요청에 대한 언급이 있습니다.
CFQ는 I/O 작업(동기 요청)을 요청하는 프로세스에 대해 프로세스별 대기열을 유지 관리합니다. 비동기식 요청의 경우 모든 프로세스의 모든 요청은 해당 프로세스의 I/O 우선순위에 따라 일괄 처리됩니다.
사용자 공간 관점에서 이 문서의 차이점을 정확히 어떻게 이해해야 합니까? 동기화/비동기라는 몇 가지 차이점이 있기 때문에 명확하지 않습니다.
- 일반
read()
/write()
통화, Linux AIO 사용(io_submit()
/io_getevents
). - flag
O_SYNC
, 설정할 때 설정할 수 있습니다.open()
하나의 문서.
(제가 이해한 한,IO 우선순위에 대한 위의 인용문은 단순 버퍼 쓰기에는 적용되지 않습니다.. IO 우선순위는 이러한 요청에 영향을 미치지 않습니다. )
답변1
Linux IO 스케줄러에서 처리하는 요청 형식에 대한 다양한 "힌트" 설정이 있습니다. 그 중 하나는 "동기화" 프롬프트입니다.
Linux의 모든 IO는 비동기식으로 처리됩니다. 이는 백그라운드 쓰기에는 괜찮지만 누군가가 완료를 기다리고 있는 읽기 또는 쓰기의 경우 블록 계층과 IO 스케줄러에 이를 알리고 싶습니다. 이를 통해 더 나은 일정 결정을 내릴 수 있습니다. 따라서 아래에서 "동기화" 및 "비동기화"가 참조되면 이 우선순위 힌트를 참조하는 것입니다.
--/linux/fs.h를 포함합니다.(2016-11-01)
읽기 요청은 항상 동기로 간주됩니다.
차단: READ_SYNC 정의에서 REQ_SYNC를 사용하지 마세요.(2016-11-01)
읽기는 정의에 따라 동기식이므로 다른 플래그를 추가하지 마세요.
O_DIRECT
쓰기는 O_SYNC
동기식으로 간주됩니다.
#define READ_SYNC 0
#define WRITE_SYNC (REQ_SYNC | REQ_NOIDLE)
#define WRITE_ODIRECT REQ_SYNC
fsync()
쓰기와 동일한 프롬프트를 사용하여 IO 요청을 시작합니다 O_SYNC
. IO 요청이 이미 시작되었고 fsync()
기존 요청을 기다려야 하는 경우 요청을 조정하는 메커니즘은 보이지 않습니다.
답변: READ_META, READ_SYNC, WRITE_SYNC 등을 이해해 보세요.(2010)
하지만 이로 인해 데이터 무결성을 위해 유휴 로직->쓰기 페이지를 비활성화해도 괜찮은 이유는 무엇입니까?라는 질문이 남습니다. 이는 ->fsync 또는 O_SYNC 쓰기에서 호출되며 O_DIRECT 쓰기와 동일한 효과를 갖습니다.
우리는 이에 대해 유휴 상태를 활성화하지 않았습니다. O_SYNC도 좋은 향상을 얻을 것입니다. 벤치마킹하고 테스트하면 추가하지 않을 이유가 없습니다.
작년에 a64c8610bd3b의 ->writepage 커밋에서 모든 종류의 동기화 태그를 사용하기 시작했습니다. "block_write_full_page: WBC_SYNC_ALL 쓰기 저장에 동기 쓰기 사용"
"유휴 비활성화"는 설명하기가 약간 어려운 다른 프롬프트 플래그입니다. 그러나 위 인용문에 연결된 커밋은 WRITE_SYNC 힌트의 사용을 확인합니다 fsync()
.
위에 참조된 코드는 이동되거나 교체되었지만 "동기화" 프롬프트의 사용은 2016년과 동일해야 합니다.
그래서 Linux AIO를 사용하여 요청을 하느냐 안 하느냐는 중요하지 않다고 생각합니다.
AIO는 O_DIRECT만 지원하므로 IO 스케줄러의 관점에서 볼 때 모든 AIO는 "동기화"되어야 합니다. :-). 적어도 v4.20 이후로는요. 이것새로운 AIO 인터페이스 제안버퍼링된(O_DIRECT가 아닌) IO를 지원합니다. 위와 동일한 코드가 실행되므로 O_SYNC 사용 여부에 따라 프롬프트가 계속 설정됩니다.
sync_file_range()
비동기 쓰기 저장이 트리거될 수 있도록 설계되었습니다. 현재 구현(Linux v4.20)에서는 REQ_SYNC
쓰기 저장 모드를 사용하여 이를 설정하지 않습니다 WB_SYNC_NONE
. 프로그램이 이 플래그를 포함하여 쓰기 저장을 기다리는 경우에도 마찬가지입니다 SYNC_FILE_RANGE_WAIT_AFTER
. 그러나 v2.6.29와 v4.4 사이의 커널 사용은 올바르지 WB_SYNC_ALL
않습니다 .REQ_SYNC
sync_file_range()