pread/pwrite, 버퍼 및 디스크 캐시

Question

코드가 fd = open("/dev/sdXY", ...) 및 pwrite(fd, ...)/pread(fd, ...)과 같은 경우 I/O 작업을 수행하여 버퍼 또는 디스크 캐시를 건너 뛰시겠습니까? /dev/sdXY은 마운트되지 않은, 포맷 된 디스크 파티션 (ext4, ufs 등)입니다.

나는 작업중인 응용 프로그램에서 인접한 파일 저장소를 부여 할 필요가 있기 때문에 내가 설명하는 것과 같은 일을 수행하는 유일한 방법이라고 읽어야합니다. 그러나 버퍼, 디스크 캐시 또는 기타 유용한 기능을 잃어 버리면 인접한 저장소에 대한 필요성을 제거 할 수 있습니다.

파티션이 이미 파일 시스템으로 포맷되었으므로 저수준 항목을 다시 구현해야하는지 혼란 스럽습니다. 나는 이것이 RAW 디스크/파티션의 경우 일 것이라고 읽었습니다. 이미 블록이 자유롭거나 사용 중인지, 파일 및 폴더 구조 등을 처리해야 할 필요가 있음을 이미 알고 있습니다. 이미이 작업을하고 있습니다.

또 다른 질문 : 약 fopen()/fread()/fwrite() 및 C++의 파일 스트림에 대해서 읽었을 때 버퍼에 대해서만 보았습니다. 이 스트림들과 f* 계열의 함수들만이 open/write/read/pwrite/pread /와 달리 일종의 버퍼를 가지고있는 것이 맞습니까? 이 버퍼가 디스크 캐시와 다른가요?

마지막 하나 : HDD 캐시가 자체 드라이브 또는 파일 시스템 (ext4, ufs 등)으로 처리됩니까?

Answer 1

간단한 답변은 '의존적'입니다. 열심히하는 것은 그것이 의존하는 것을 특징 짓는 것입니다.

단순히 open()을 사용하면 커널 디스크 버퍼 풀이 발생하지 않습니다. 이를 위해서는 Linux에서 특별 옵션 (O_DIRECT)이 필요합니다. 그러나 open()을 사용하면 숨겨진 응용 프로그램 버퍼를 사용하지 않아도됩니다. 중간 복사본없이 데이터를 읽거나 쓰는 위치를 선택할 수 있습니다. 대조적으로, f* 계열의 함수에는 '숨겨진'응용 프로그램 버퍼가 있습니다. 데이터는 FILE * 파일 스트림과 관련된 I/O 버퍼로 자주 읽은 다음 응용 프로그램 버퍼로 복사됩니다.

/dev/sdXY 장치가 이미 파일 시스템으로 포맷되었지만 파일에 연속 된 파일 저장소를 보장하려는 경우 파일 시스템 드라이버의 상당 부분을 복제하여 공간을 올바르게 할당해야합니다. 그것은 당신의 시간이나 에너지를 합리적으로 사용하는 것 같지 않습니다. 예, 모든 종류의 저수준 디스크 공간 관리를 다시 구현해야합니다. 이는 전혀 사소한 일입니다. 또한 ext4의 구현은 ufs 등의 구현과 상당히 다를 수 있으므로 실제로 작업해야 할 부분이 있습니다.